Your first conversation.

Start in the console

Sign in, set up an authenticator and create your developer workspace using the staging draft terms. An Owner or Admin can add the project-planning demo from Browse catalog or start it in the sandbox. Trying it in the sandbox needs no API key or deposit.

To connect your application, open My APIs and create a staging key for the demo with the permissions your integration needs. The API calls this workspace access an assignment; its ID is shown in My APIs. Keep the key in your server’s secret store. The browser console uses your verified sign-in; server keys must never appear in browser code.

Personas, configuration and private APIs

ForeverLearning configures the API’s persona, instructions, memory rules, response format and usage limits. Together, these make up a release. Your workspace’s access determines which release your application uses; you can see it in My APIs.

Existing conversations retain their release and rate when a new release is assigned. Private capabilities use the same chat, replay, closeout and privacy interfaces; their configuration and display contract can differ.

Need a custom persona or workflow? We agree on scope and usage terms before building it. See pricing for the setup offer.

Send a turn from your server

Use the dedicated staging origin below. Send a stable, opaque X-User-Id for the person using your product, and the granted X-Assignment-Id. The service scopes that identity to your organization and assignment.

curl --no-buffer https://developers-api-staging.foreverlearning.ai/v1/chat \
  -H "Authorization: Bearer $FL_API_KEY" \
  -H "Content-Type: application/json" \
  -H "X-User-Id: project-user-42" \
  -H "X-Assignment-Id: $FL_ASSIGNMENT_ID" \
  -H "FL-API-Version: 2026-12-01" \
  -H "Idempotency-Key: project-user-42-turn-001" \
  --data '{"prompt":"Help me plan a small community project."}'

Give each new turn its own idempotency key and keep it with the exact original body. For a continuation, add the returned sessionId as the body’s session_id. Omitting it requests a new session and may first close an existing one.

The assigned release controls its opening behavior and workload allowance. The project-planning demo starts with your first message. You cannot choose a model, replace server memory or supply conversation history through this request.

Read the complete outcome

Check the HTTP status and Content-Type. Successful chat responses use text/event-stream; each blank-line-delimited frame contains a JSON data: payload. Dispatch on its type. There is no [DONE] sentinel.

Display text as it arrives, but mark the turn complete only after done. Check that its session and request identities agree with the opening metadata. A closeout also requires session_ended. Ignore additional fields and unknown future events without bypassing these completion checks.

The commercial receipt preserves the original listing, reasoning band and rate version. Charges are integer microdollars: 1,000,000 microdollars equals $1 USD. A free sandbox receipt has zero charge.

Recover without creating another turn

If the connection breaks or ends before done, the work may still be running. Read GET /v1/requests/{request_id} with the same identity and assignment headers. This lookup never starts another provider call. Only a committed result is successful; in_progress and unavailable require further resolution.

When retrying the original POST, preserve both the idempotency key and exact body. Changing input under an existing key returns 422 IDEMPOTENCY_KEY_REUSED. Omitting the key can create a new request. Do not infer a released charge or permission to start again from a lost connection.

JSON refusals contain error: true, code, message and request_id. A failure after streaming starts arrives as an error event without successful completion. Correct authentication or permissions for 401/403; inspect balance or budget for 402; for 409, resolve pending work, or after REQUEST_FAILED send the request again with a new key; respect limits for 429. Use a retry delay only when the response supplies one.

Manage sessions and privacy deliberately

Use sessions:read to retrieve existing session status and newest-first history. Reuse opaque pagination cursors unchanged. Ending a session runs governed closeout; discarding or deleting it has a different purpose. Lifecycle changes take a durable operation_id that must remain unchanged on retries.

Privacy export and erasure require their own authority and scopes. Collect every export page until next_cursor is null. Erasure is complete only when its durable receipt says completed; financial records and required obligations are retained.

Console access requires MFA, and sensitive changes require recent verification. Optional signed safety webhooks carry minimal event information. Your product owns its end-user escalation path; ForeverLearning does not provide staffed real-time monitoring.