Overview
- Version:
v1 - Endpoints:
3 - Base path:
/api/partner/v1/core-chat - Source: Migrated from
https://www.brek.ai/docs/partner-core-chaton February 19, 2026.
Onboard now action
- Contact
leo@pageonelab.com. - Brek will issue your partner API key (and sandbox base URL).
- Start testing with Postman or your own HTTP client.
Authentication (API key usage)
Send one of these headers on every request (POST /sessions,
POST /events, GET /sessions/{sessionId}):
x-partner-api-key: <partner_api_key>(recommended)Authorization: Bearer <partner_api_key>api-key: <partner_api_key>
POST /events uses the same auth header:
Base path
/api/partner/v1/core-chat
Common response headers
x-request-id: request trace IDx-ratelimit-limitx-ratelimit-remainingx-partner-id
POST /sessions
Creates a new partner chat session.
Input variables (field | definition | required):
actor.actorId| Stable end-user ID in your partner system (for profile/history continuity). |Yesactor.timezoneOffsetMinutes| End-user timezone offset in minutes (for date parsing like “tomorrow”). |Nochannel.workspaceId| Optional partner workspace/group identifier used for routing/analytics. |Noconversation.channelId| Optional conversation bucket key from your client app. |Noconversation.id| Optional explicit conversation ID for your own traceability. |Noconversation.threadTs| Optional explicit thread key for your own thread model. |No
x-partner-api-key: <partner_api_key>(orAuthorization: Bearer <partner_api_key>, orapi-key)
201):
POST /events
Sends one event into an existing session.
Input variables (field | definition | required):
sessionId| Session ID returned byPOST /sessions. |Yesactor.actorId| Optional safety check. If provided, it must match the actor bound to the session. |Notext| Natural-language user message. |Yesfor natural-language flowkind| Explicit event type (for action-based integrations). |No(but required for explicit action-kind calls)payload| Structured action payload (for exampleoptionId,bookingId,paymentMethodId). |No(but required by certainkindvalues)idempotencyKey| Client idempotency token to make write retries safe. |No(required for write kinds listed below)
x-partner-api-key: <partner_api_key>(orAuthorization: Bearer <partner_api_key>, orapi-key)
- Persist
sessionIdbyactorIdon your side. Reusing one session across different actors will mix user state.
kind behavior:
- Optional for normal natural-language messages.
- Required only when you explicitly call action kinds (for example:
action_book_option,action_cancel_booking).
data.result.status= action/state code for your UI logic.data.result.message.text= assistant text to render to end users.data.result.artifacts= structured payload (shortlist, payment setup URL, booking confirmation, etc.).
command_book_by_option_idaction_book_optionaction_confirm_price_changeaction_confirm_payment_cardaction_cancel_booking
200):
GET /sessions/{sessionId}
Returns current session snapshot and event history.
Input variables (field | definition | required):
sessionId(path) | Existing session ID. Must belong to your partner tenant. |Yes
x-partner-api-key: <partner_api_key>(orAuthorization: Bearer <partner_api_key>, orapi-key)
200):
Golden path example (search -> booking intent -> guest name -> payment setup -> done -> booked)
The sequence below was captured from a real sandbox run on February 18, 2026.Step 0: Create session
Variables for this step (field | definition | required):
actor.actorId| Stable end-user ID in your partner system. |Yesactor.timezoneOffsetMinutes| User timezone offset in minutes. |Nochannel.workspaceId| Optional partner workspace/group identifier. |Noconversation.channelId| Optional conversation key in your client app. |No
POST /sessions):
201):
Step 1: Search request
Variables for this step (field | definition | required):
sessionId| Session ID returned in Step 0. |Yestext| Natural-language search request from the user. |YesidempotencyKey| Retry-safe dedupe key from partner side. |Recommended
POST /events):
status=shortlist):
Step 2: User asks to book option 1
Variables for this step (field | definition | required):
sessionId| Session ID returned in Step 0. |Yestext| User booking-intent message. |Yes
POST /events):
status=guest_name_required):
Step 3: User provides guest name
Variables for this step (field | definition | required):
sessionId| Session ID returned in Step 0. |Yestext| Guest-name message (for example: “guest name is John Doe”). |Yes
POST /events):
status=payment_setup_required):
Step 3.5: User finishes card setup in payment portal
This happens outside Partner Core Chat endpoints (in Brek payment stack), but shown here for end-to-end clarity. Variables for this step (field | definition | required):
portalToken| Payment setup token returned inartifacts.payment.setupUrl. |YespaymentMethodId| Payment method token from payment provider. |YescardBrand| Card brand (for examplevisa). |YescardLast4| Last 4 digits of card. |YesexpMonth| Card expiration month. |YesexpYear| Card expiration year. |YessetAsDefault| Whether to set this card as default. |No
POST /v1/hotel-ea/payment-methods/attach on Brek payment
backend):
Step 4: User returns to chat and says “Done”
Variables for this step (field | definition | required):
sessionId| Session ID returned in Step 0. |Yestext| Completion message after card setup (for example: “Done”). |Yes
POST /events):
status=payment_confirmation_required):
Step 5: User confirms payment and booking
Variables for this step (field | definition | required):
sessionId| Session ID returned in Step 0. |Yestext| Confirmation message (for example: “yes, use this card”). |Yes
POST /events):
status=booked + confirmationUrl):
More scenarios and outputs
Scenario A: user says “Done” but card is not attached yet
Variables for this scenario (field | definition | required):
sessionId| Existing session ID. |Yestext| Completion message (for example: “Done”). |Yes
POST /events):
status=payment_setup_required again):
Scenario B: user already has a saved card
Variables for this scenario (field | definition | required):
sessionId| Existing session ID. |Yestext| Guest-name message after booking intent. |Yes
POST /events, after guest name):
status=payment_confirmation_required, no setup URL):
Scenario C: user declines payment confirmation
Variables for this scenario (field | definition | required):
sessionId| Existing session ID. |Yestext| Decline message (for example: “no”). |Yes
POST /events):
Error responses
Missing API key (401):
403):
400):
404):
Retry guidance
- Retry
429and5xxwith exponential backoff. - Reuse the same
idempotencyKeywhen retrying write actions. - Log
x-request-idfor every failed request.
Security requirements
- Keep partner API keys server-side only.
- Use HTTPS/TLS for all requests.
- Do not send raw PCI card data in chat payloads.