Plans and add-ons

Listings and Social tiers, what each includes, the price of every add-on, how proration works, and the caps that stop a self-serve account growing further.

Listings API sells two products. Listings manages business locations and their directory presence. Social manages brands and publishes to their social accounts. They are priced separately, billed separately, and capped separately.

Listings

Listings tiers are priced on the number of locations you may have.

Every location on the plan gets the full directory network, review management, posts and analytics. The tier changes how many locations you may hold and your request budget, not which endpoints you can call.

Social

Social tiers are priced on the number of connections you may hold. A connection is one social account — a Facebook Page, an Instagram Business account, an X account, a LinkedIn organisation, a Pinterest board — linked to one brand on one network through a connection link.

Brands are unlimited and unmetered on every tier. A brand is just the container that owns connected accounts and the posts published from them; creating one costs nothing and is never refused for a cap. POST /social/brands has no brand limit on an API plan.

Connections are what you are buying. The five supported networks mean one fully connected brand consumes five connections, so 20 connections is roughly four brands connected everywhere, and 125 is roughly twenty-five — but nothing forces that split. You can spread 125 connections across sixty brands on two networks each, or concentrate them on a handful.

Add-ons

Add-ons are published prices and can be bought at any time, without moving tier.

Connection packs stack. They are bought by quantity, so two packs are $50/mo for 10 extra connections, three are $75/mo for 15, and so on. There is no per-brand add-on and no way to buy a single connection: five is the unit. A pack is untyped: it adds five connections to the pool and you decide which networks and brands they go to.

Connections are an account-wide pool

Connections are not allocated per brand. Your tier and your packs add up to one account-wide pool that any brand may draw from:

maxConnections = tier connections + (5 × connection packs)

On Social Growth with two packs, an account has 125 + 10 = 135 connections available, and one brand may hold twelve of them while another holds one. There is no per-brand connection limit — only the pool.

A slot is spent for the whole billing period, not just while it is connected. The pool is metered on the distinct connections an account has used during the current period, so disconnecting a channel takes it offline immediately but leaves its slot spent until the period renews. This is the same rule as every other reduction on the account — see Proration — and it means the pool cannot be recycled inside a cycle: connect 20, disconnect them, and you are still at 20 until renewal.

Two things follow. Relinking the same social account to the same brand is free, because it reuses the slot that account already holds on that brand. A slot belongs to one brand-and-account pair, so attaching the same account to a different brand takes a second slot, and the first one stays held until the cycle turns. And buying a pack is the only way to add capacity mid-period, since add-ons are charged and granted immediately while released slots wait for the cycle to turn.

GET /social/limits reports the whole picture:

Headroom is maxConnections - usage.connections. Running out of pool returns SY95042 from the connection link — which is why a developer who has just disconnected several accounts can still be refused. Brand create has no equivalent failure on an API plan.

Self-serve caps

Two hard ceilings apply no matter how many add-ons are purchased:

• 100 locations on a self-serve Listings account.
• 250 connections on a self-serve Social account.

There is no brand ceiling: brands are unlimited, and an account can hold as many as it likes as long as the connections those brands use stay inside the pool.

Above either ceiling the account has to move to Enterprise, where the caps are negotiated — contact sales rather than buying more packs. An account with no Listings plan at all cannot create locations and gets SY10155; the equivalent for Social is simply having no Social subscription, in which case every /social/* endpoint is unavailable.

Adding the second product

An account that holds one product can buy the other from the dashboard, without talking to sales and without a new account. Each product keeps its own subscription, its own renewal date and its own cancellation, exactly as if you had bought them separately.

Each product carries its own free trial. The Launch tier of a product you have never held starts with 14 days free, even if you are already a paying customer on the other product. A Listings Growth customer who adds Social Launch gets Social's own 14 days on its own renewal date, and their Listings billing continues untouched. The same holds in reverse for a Social customer adding Listings Launch.

Everything above Launch is billed on the day you buy it, and Enterprise on either product is scoped with us rather than sold self-serve.

The trial is once per product. If you have already trialled a product, buying it again is charged immediately — there is no second free period for the same product. Buying an add-on while a subscription is still trialling ends that trial and starts paid billing, which the dashboard confirms before it happens.

Proration

Add-ons are charged immediately. Buying an extra location or a connection pack takes effect at once and is invoiced on the spot, prorated for the remainder of the current billing cycle. You do not wait for the cycle to turn to use the capacity you just bought.

Reductions take effect at the end of the billing cycle. Nothing you give up is refunded for the remainder of the period, and nothing you give up frees capacity before the cycle closes. This one rule covers every reduction on either product:

So a released connection slot behaves exactly like a cancelled add-on: the consequence lands at the period boundary, not on the API call. It is reported while you wait as usage.connectionsReleased on GET /social/limits, which is your forecast of the capacity that comes back.

This asymmetry is deliberate: you can always grow now and pay for exactly what you used, and you never lose capacity you have already paid for — nor reuse it twice in the same period.

The 90-day tenure rule

A location or a brand must be at least 90 days old before it can be archived. Both POST /locations/archive and POST /social/brands/archive enforce it; the brand endpoint reports it as status: "TENURE_NOT_MET" with SY95051.

The rule exists because archival is how a subscription shrinks, and a resource created and archived inside one cycle would otherwise cost nothing. It has one practical consequence worth designing around: a brand or location created by mistake cannot be removed for 90 days. Validate before you create.

What happens once tenure is met differs by product:

• Brands archive immediately, but their connection slots do not come back immediately. The brand and every connection linked to it are archived in the same request and go offline at once; each of those slots is then held to the end of the billing cycle, exactly as a direct disconnect would be. GET /social/limits shows the drop in usage.connectionsActive and the matching rise in usage.connectionsReleased on the next read, with the billable usage.connections unchanged until renewal. The archival itself has no scheduled state and nothing to cancel.
• Locations are scheduled for the end of the billing cycle. The location stays live and keeps counting against your Listings cap until the cycle closes, and the decision is reversible until then with cancel a location archival.

Reading your own limits

Check the relevant cap before a create rather than after a failure: it lets you show a customer an upgrade path instead of an error code.