> ## Documentation Index > Fetch the complete documentation index at: https://docs.wpos.ai/llms.txt > Use this file to discover all available pages before exploring further. # Concepts > The handful of ideas the Partner Program is built on: partners, managed accounts, sites, credits, build jobs, scopes, and webhooks. A short glossary. Everything else in this section assumes these. ## Partner Your organization, as WPOS sees it. A partner has a name, a slug, default branding, an optional account cap, a default plan for the accounts you create, and an optional webhook endpoint. Every account, key, and build job belongs to exactly one partner. ## Managed account A customer account you provision and own. It is a normal WPOS account with one difference: it is marked partner-managed, so it carries no WPOS-facing billing and the WPOS checkout surfaces are closed to it. You reference each account by your own `externalRef` (for example your workspace or customer id), and WPOS keeps provisioning idempotent on the pair of your partner id and that ref. ## Site A WordPress site connected to one of your managed accounts through the WPOS plugin. Sites are where the agent actually works. You do not create sites by API; they appear once the plugin on a real WordPress site registers against an account you provisioned. ## Credits The unit WPOS meters work in. A build job consumes credits based on its cost. You hold your customers' credits: grant them to an account, watch the balance, and get a `credits.low` webhook before an account runs dry. Because accounts are partner-managed, credits are yours to price and resell. ## Build job One headless run of the WPOS agent against one site. You submit a plain-language instruction plus optional structured context, WPOS runs the agent with no human in the loop, and you poll for a structured result (a summary, the changes it made, and any warnings). See [Build jobs](/partners/build-jobs). ## The embedded assistant The WPOS agent, running inside your own product in an iframe, branded as yours. It comes in two roles: `manager` for your operators and `client` for your end customers. The browser never holds your API key; each session is a short-lived, site-scoped token you mint. See [Embed the assistant](/partners/embed). ## API key and scopes You authenticate to the Partner API with an `X-Partner-Key` header. Each key carries a set of scopes that gate what it can do: | Scope | Grants | | ----------- | ----------------------------------------------------------------- | | `read` | Read accounts, sites, and job status. | | `provision` | Create accounts, change plans, grant credits, set account status. | | `handoff` | Set white-label branding on a site. | | `jobs` | Submit, poll, and cancel build jobs. | | `embed` | Mint embedded-assistant sessions. | We issue keys with the scopes your integration needs. Treat a key like a password: it is shown once, stored only as a hash, and is revocable. See [Authentication](/partners/api-reference#authentication). ## Webhook An HTTP callback WPOS sends to your endpoint when something happens: a site connected, credits crossed the low threshold, a build job finished. Every delivery is signed so you can verify it came from WPOS. See [Webhooks](/partners/webhooks). ## Next Put these together: provision an account and run a build job.