Embeds
An embed puts a CloudRaker view on your page. Your users review extracted values, correct them and approve them without a CloudRaker account. Your backend creates a short-lived embed session with your API key. Your page loads the session URL in an iframe.
The embed has three views:
In write mode, the person can edit values and approve a document. Each saved change and each approval sends a signed webhook and a message to your page.
How it works
Run an extraction
Call POST /v1/extract with the default unit per_document. Wait until the run status is processed.
Create a session on your backend
Call POST /v1/embeds with your API key. Send the run, the mode, the origins of the pages that show the iframe and, optionally, the person, a webhook and a theme. The response has a url.
Put the URL in an iframe
Send url to your page and set it as the src of an iframe. The session token is in the URL fragment. Treat the URL as a secret.
Create sessions on your backend only. Your API key must never reach the browser. Create a new session for each person and each visit. Do not share a session URL between people.
Create a session
The response is 201:
A transcript session binds one file:
Put the iframe on your page
- Your page sets the size. The embed fills the frame.
allow="clipboard-write"lets the person copy values.- The page must be one of the session
origins. When a page from another origin frames the embed, the embed refuses to render and sends no message. - The embed removes the token from its address bar after it loads. A reload of the iframe keeps the session.
If you sandbox the iframe, use exactly these flags:
A sandbox without allow-same-origin gives the frame an opaque origin. The embed does not support that.
Messages to your page
The embed posts messages to window.parent. It sends them only to an origin in the session origins, never to *. It ignores all messages that your page sends to it.
document has the same shape as a document in GET /v1/runs/:id: fileId, name, value and citations.
Always check the origin and the session id before you use a message:
trusted: false means what it says. A message is a UI signal only. The browser can change it. Use the signed webhook, or GET /v1/runs/:id, as the record of a save or an approval.
In read mode, the embed posts only ready and error.
Webhooks
A write session sends two event types:
A save with no change sends nothing. The events go to the session webhook and to every saved endpoint of your organization that subscribes to the type, or to all types. Each endpoint gets one delivery per event.
documentis the full document after the change, not a diff.changedKeyslists the fields that changed.- An edited field loses its citation.
useris absent when the session has no user.metadatais absent when the session has none.eventIdis stable across retries. A save and an approval at the samerevhave different ids. Dedupe oneventId.- CloudRaker does not store an approval state. Record the approval on your side when you receive the event.
Verify every delivery. Embed events use the same signature as all other events: the x-rk1-signature ES256 JWT, checked against GET /v1/webhooks/jwks.json, with iss rakerone-process and a bodySha256 claim for the raw body. The webhooks page has the steps and sample verifiers. In short:
Embed delivery is best effort. Each event gets up to 5 attempts, about 0.5, 1, 2 and 4 seconds apart, with a 10-second timeout on each attempt. The change stays saved in CloudRaker when all attempts fail. GET /v1/runs/:id shows it, and your page also gets the message.
Save conflicts (rev)
Each document has a revision number, rev. It starts at 0. Each saved change adds 1.
The embed sends the rev it loaded with each save. If the document changed after the page loaded, the save fails. For example, a colleague edited it in the CloudRaker app, or in another session. The embed then:
- shows the banner “This document changed after you opened it.” with a Reload button. Reload loads the current values and drops the local edits.
- posts an
errormessage with codeconflict.
A stale approval fails in the same way. Events can arrive out of order. Use rev to keep the newest version of each document.
Themes
Send theme to match your app. All keys are optional. An unknown key or a value that does not match its pattern is a 400.
The color keys are:
background, foreground, card, card-foreground, popover, popover-foreground, primary, primary-foreground, secondary, secondary-foreground, muted, muted-foreground, accent, accent-foreground, destructive, border, input, ring.
The patterns accept only plain values. Other CSS (url(, var(, ;, { and comments) always fails. The confidence rating colors do not change with the theme.
Identity
user is the person who uses the view, as your system knows them: { id, name, email? }.
- CloudRaker does not verify it. It stores it as you send it.
- The audit log names the person as
ext:<id>with the given name, and marks the identity as not verified. - Webhooks carry
{ id, name, verified: false }. - The email stays with CloudRaker. No webhook, message or audit event contains it.
Revoke a session
The response is 204, also for a session that is already revoked. The iframe stops working on its next request. There is no route to list or read sessions, so store the id when you create a session.
Limits
Origin onboarding
The embed shows only on pages that CloudRaker allows to frame it. Before you go live, send the exact origins of your pages (for example https://emr.partner.example) to your account team. CloudRaker adds them to the allowed list. The origins of each session must be on that list.
On test environments, http://localhost and http://127.0.0.1 on any port are allowed.