Bindings

A binding is a service the platform provides to your app. Your app says which ones it wants in cohostly.json. The platform then gives it an address and a token for each. The real keys for the provider behind a service never enter your app, so there is nothing in your code to leak.

Think of a hotel room with a phone. You can call room service, but you never get the kitchen's keys.

What is available

Turn one on

Say so in cohostly.json:

{
  "manifest_version": 2,
  "name": "my-app",
  "bindings": {
    "ai": { "models": ["claude-haiku-5-5"], "monthly_cap_usd": 5 },
    "data": { "managed": true },
    "cron": { "code": true },
    "approvals": { "enabled": true }
  }
}

Then generate the typed platform object and import it:

cohostly types --project my-app

import platform from './platform.gen.js'

Details are in the platform object.

Rules that stop the common mistakes

1. Declare what you use. A call to a binding the settings file does not declare fails.
2. Do not hold the token. Do not log it, hand it to a browser or write it to a file.
3. Handle refusals. A call can be refused: a spending cap reached, a rule said no, a person has not yet connected their account. These are normal answers. Show the plain message and stop. Do not loop.
4. Do not go around. If a call is refused for a policy reason, the policy belongs to the project's owner. Do not call the provider directly to get the answer.
5. Local runs. cohostly dev --project my-app -- <command> gives your machine the same addresses and a temporary token (develop).

Which one for what

• Environment variables: the variables the platform sets for each binding.
• A chatbot or summary: ai.
• Notes, orders, scores, anything kept per person: data.
• Saving a form into a spreadsheet, reading a calendar: connections.
• Deleting, emailing a list, spending money: ask first with approvals.
• A daily report, a reminder: cron.