Overview

Tabbio is a career platform in the Gulf. People keep a CV there, apply to jobs, and maintain a public profile. Two APIs open that up to your product.

Sign in with Tabbio puts a "Continue with Tabbio" button on your site. A person signs in, chooses what to share, and you receive their identity and their CV. The CV is not a one-time upload: when they edit it in Tabbio, your copy is already current the next time you read it.

The partner API is for platforms acting on behalf of employers. Create company pages, post and publish jobs, and read the people who applied, all from your own systems with a server-side API key.

Quickstart

The whole sign-in flow in Node, from client id to CV, in about ten minutes.

Create an API key

The partner API path: keys, scopes, and what each scope reaches.

Base URLs

Field	Type	Description
https://server.tabbio.com	API	Every request in this documentation, unless it says otherwise.
https://app.tabbio.com	Browser	The consent screen, and Settings > Connected apps where a person manages what they shared.
https://platform.tabbio.com	Browser	The developer platform: your apps, credentials, usage, request log and limits.
https://developer.tabbio.com	Docs	This site.

If your OAuth client can read a discovery document, point it at https://server.tabbio.com/.well-known/oauth-authorization-server and every endpoint is configured for you. The machine readable description of everything else is served at https://server.tabbio.com/v1/openapi.json, which is what this reference is generated from: point an SDK generator or a coding agent straight at it.

Credentials

You create an app once, on the developer platform. Sign in with your Tabbio account or create a developer login, then create an app under Applications. That app owns everything else. The developer platform guide is a tour of the rest of it.

Field	Type	Description
tbo_ci_	Client id	Public. Identifies your app in the authorization request. Safe in a browser or a mobile binary.
tbo_cs_required	Client secret	Server side only. Shown once when you create or rotate it.
tbo_sk_required	API key	Server side only. Carries company scopes for the partner API.

An app can be confidential (it has a server that can keep a secret) or public (a single page app or a mobile app that cannot). Public clients skip the client secret and rely on PKCE, which is required for both kinds anyway.

Secrets belong on a server

A client secret or an API key in browser JavaScript is public the moment you ship it. If your integration has no backend, register a public client and use PKCE alone.

The response envelope

Every JSON response carries the same three keys.

JSON

{
  "data": { "id": "usr_2f8a", "name": "Sara Ahmed" },
  "error": null,
  "meta": null
}

On failure, data is null and error names what went wrong.

JSON

{
  "data": null,
  "error": {
    "code": "OAUTH_INSUFFICIENT_SCOPE",
    "message": "This token does not carry the cv:read scope."
  },
  "meta": null
}

Branch on error.code. It is stable. The message is written for a person reading a log and can be reworded at any time.

meta carries paging on list endpoints. Every list in this API is page based; there are no cursors anywhere.

JSON

{
  "data": [],
  "error": null,
  "meta": { "page": 1, "pageSize": 25, "total": 63, "totalPages": 3 }
}

Four things are deliberately unwrapped: POST /oauth/token and POST /oauth/introspect, which answer the flat bodies RFC 6749 and RFC 7662 define, the discovery document, which follows RFC 8414, and the two PDF endpoints, which stream a file. POST /oauth/revoke keeps the envelope, because RFC 7009 specifies no success body of its own.

Versioning

Partner resources live under /v1. Inside a version, fields are added but never removed or retyped, so parse leniently and ignore keys you do not recognise. A change that would break clients ships as /v2 next to /v1.

The OAuth endpoints are not versioned. They implement published standards rather than a Tabbio shape, so there is nothing Tabbio-specific to version.

What is not here yet

Webhooks, an OpenID Connect id_token, the client credentials grant, and dynamic client registration are all planned and none of them exist today. Poll for CV changes with an ETag, described in Reading the live CV, rather than waiting for an event that will not arrive.

There is also no write access to applications: you can read candidates, not move them through a pipeline.