Access and keys

How do I get access?

A Bidlo account is required. Anyone can get one by booking a call at https://cal.com/matt-wolfe-yecrho/30min — Bidlo sets the team up, and a team owner or admin then mints the API key in Settings → Features → API. There is no public tier and no self-serve signup.

If your company is already on Bidlo, you do not need the call: ask an owner or admin on your team for a key.

Book a call

Who can create a key?

Only a team owner or admin can create an API key, in the Bidlo app under Settings → Features → API.

Two screens in the app mint the same kind of key.

Only they can see or delete a team’s keys. Give each integration its own key.

What does a key look like?

A key is the prefix sk_live_ followed by 48 hexadecimal characters, and Bidlo shows it once.

That is 56 characters in all. Bidlo keeps a hash of the key rather than the key, so it can check one and can never print one again. The list in Settings shows each key by its label and its last four characters, which is enough to tell two apart and not enough to use.

Copy the key when you create it. A key that was not copied is not recoverable: delete it and make another.

Keep the key on a server, never in browser code. The REST API sends no CORS headers, so a browser cannot call it anyway.

How do I send the key?

Send it in an Authorization header on every request, as the word Bearer, a space, then the key; the MCP server and the REST API read the same header.

The header is the same line either way. YOUR_API_KEY stands for the key you minted.

Authorization: Bearer YOUR_API_KEY

https://app.bidlo.ai/api/v1

REST takes the header on every method. The key carries its team, so a request sends no team_id; one sent anyway is refused with a 422. The REST API page covers the older routes that still ask for one.

curl https://app.bidlo.ai/api/v1/collections \
  -H "Authorization: Bearer YOUR_API_KEY"

The MCP server reads the same header. An MCP client sends it once the key is in its config; the MCP server page has a config for each kind of client.

What can a key do?

A key does what its access allows, in the collections it is limited to, until it expires; all three are chosen when the key is made.

None of the three can be changed later. To change what a key can do, make a new one and delete the old one.

Access

The Access menu has four choices.

Three permissions work in the API today.

Settings marks views, flows, webhooks and team permissions Coming soon and disables them. Pick Read only unless the integration writes.

Collections

A key reaches all collections by default. Pick certain collections and the key can reach only those; anything else is refused with a 403. A key limited to certain collections cannot create a collection. Relations and formula dependencies must also stay within the key’s access.

Expires

Choose Never, In 30 days, In 90 days or In 1 year. After that date every request with the key is a 401.

Who does a key act as?

A key acts as the person who created it, so it can never do more than that person’s team role allows today.

The key list in Settings shows that person beside each key, as Acts as and their name.

• If the creator is a viewer on the team, the key can only read, whatever access it was given.
• If the creator is moved to a lower role, the key loses what the new role does not allow, at once.
• If the creator leaves the team, every request with the key is a 401.

A key with no creator on record is read only, whatever access it was made with. The list marks it Read only. To write, make a new key.

How do I check what a key can do?

Call GET https://app.bidlo.ai/api/v1/me, or the MCP tool me, and Bidlo answers with the key’s permissions, its collection limit and its expiry.

curl https://app.bidlo.ai/api/v1/me \
  -H "Authorization: Bearer YOUR_API_KEY"

{
  "data": {
    "key_id": "<key_id>",
    "label": "<label>",
    "team_id": "<team_id>",
    "owner_id": "<user_id>",
    "scopes": [
      "data:read",
      "data:write"
    ],
    "role": "admin",
    "collection_ids": null,
    "expires_at": null
  }
}

scopes is what the key can do now, after its creator’s role is applied: data:read is Read data and data:write is Edit data. collection_ids is null when the key reaches all collections, and expires_at is null when it never expires. The call needs Read data, like every read.

How do I revoke or rotate a key?

Delete the key to revoke it, and create another one to rotate; a key with an expiry date also stops working on that date.

Deleting takes effect on the next request: that key stops being a key. To change keys without a gap, mint before you delete.

1. Create the new key under Settings → Features → API and copy it.
2. Move every client and every server over to it.
3. Delete the old key.

An expiry is set when the key is made and cannot be moved, so a key that expires is rotated the same way. Two other things stop a key: its creator leaving the team, and the team’s subscription lapsing. Both are in the next section.

Why is my key rejected?

A missing, unknown or expired key is a 401, a key that is not allowed to do what it asked is a 403, and too many requests in a minute is a 429; the code in the error body says which.

REST answers with an error object holding the code and the message, and a request_id to quote if you write to support.

{
  "error": {
    "code": "key_expired",
    "message": "API key expired"
  },
  "request_id": "<request_id>"
}

The MCP server answers with the same status and a JSON-RPC error body; the MCP server page covers it.

Each key gets 600 reads and 120 writes a minute. The REST API page covers the rate-limit headers.