ID prefixes
Treat them as opaque
IDs encode an internal numeric primary key with URL-safe base64 (for example1
→ MQ), but that encoding is an implementation detail and is not part of the
contract. Don’t decode them, don’t parse them, and don’t assume they’re
sequential or sortable — store and echo them as strings.
The prefix is the one part you can rely on: it tells you which resource an id
belongs to, so passing a cred_... where a sess_... is expected fails fast
rather than silently resolving to the wrong record.
run_ versus run_key
Blueprint trigger responses include both an opaque run_... id and a UUID
run_key. Status polling accepts either, so pick one and stay consistent. The
run_key is the more useful of the two when correlating with your Rubie team,
since it’s what appears on the run in the dashboard.
Credential sessions
Credential sessions (sess_) are the hosted form flow described in Hosted
credential collection. They produce a
cred_... id you pass when triggering a Blueprint.
Embedded credential sessions (ecs_) add a Blueprint picker and
origin-bound iframe around credential collection. See Embedded Credential
Capture.