Skip to content
MGP
Cocomo
Book a demoBack to Cocomo Media

Three planes to integrate. That is the whole contract.

MGP does not want to be a second system of record. It publishes a catalogue your merchants can buy from, accepts orders under rules you set, and streams fulfilment back over webhooks until the report lands. Everything else stays yours.
Read the docsGet a sandbox tenancy
6 endpoints2 webhooksSandbox with fake merchantsNo PII leaves your tenancy

What each plane actually does

None of these require you to model a campaign, a creator, or an ad account. They require you to model a merchant, an order and a webhook, three things you already have.

Catalogue

GET /catalogue

MGP returns the services available to your tenancy, priced in your currency with your margin already applied. Each item carries a minimum budget, a delivery window and the inputs a merchant must supply. You render it however you like, or embed the storefront and skip the work.

  • Priced per tenancy, not per merchant
  • Localised copy for every service
  • Availability by category and geography

Ordering

POST /orders

An order is a merchant, a catalogue item, a budget and whatever inputs that item requires. Your rules run first: spend ceilings, category blocks, approval chains, consent capture. MGP only ever sees an order you already agreed to.

  • Per-merchant and per-tenancy spend ceilings
  • Idempotent, so a retried request is not a second campaign
  • Cancellable until production starts

Fulfilment

webhook: order.updated

From there it is Cocomo Media's problem. Status changes, drafts needing approval, assets, daily spend rows and the closing report all arrive on the same webhook, against the same order id.

  • Daily spend rows, ready for your billing run
  • Assets delivered with usage rights attached
  • One monthly report per merchant

An order has six states, and you can see all of them.

  1. draft

    The merchant is configuring. Nothing is charged, nothing is reserved.

  2. submitted

    Budget, consent and approvals have passed your rules. MGP takes it.

  3. in_production

    Cocomo is casting creators, building audiences or shooting.

  4. awaiting_merchant

    Something needs a human: a draft to approve, an asset to sign off.

  5. live

    The campaign is running. Spend rows arrive daily.

  6. reported

    The month closed. The report and attribution are on the order.

Every transition arrives on order.updated, with the full order body. There is no polling loop to write and no separate status endpoint to remember.

Who does what, written down before you sign anything

You keep

  • The merchant relationship, the billing and the invoice
  • The customer data, which never leaves your tenancy
  • Pricing and margin on every catalogue item
  • The right to switch a service off for any merchant, instantly
  • Your own UI, if you would rather not embed ours

MGP handles

  • Creator casting, briefing, approvals and usage rights
  • Ad account structure, pixels, catalogues and audiences
  • WhatsApp template approval and sender onboarding
  • Every piece of creative, in every language you need
  • Policy rejections, platform support and the monthly report

Integrations & API

The endpoints, the webhook payloads, the embeddable storefront and the white-label option.

Continue

Campaign engine

What happens between a merchant clicking buy and the report landing: the part you never have to build.

Continue

The questions engineering asks first

No. Attribution runs against records you expose over your own API, inside your tenancy. MGP holds order metadata, campaign state and aggregate results, never a customer list.

Ad accounts and business profiles belong to the merchant, so nothing is stranded. MGP partner access is revoked, running campaigns are wound down at the end of their flight, and the asset library stays with the merchant.

Most platforms do. WhatsApp or influencer is the usual first item because they need the least from your side. The catalogue endpoint simply returns fewer items.

Two engineers, roughly two weeks, if you already have a merchant object and a webhook consumer. Embedding the storefront instead of building your own ordering UI is what saves most of it.

Whoever the spend model says. Merchant-funded spend sits on the merchant's own payment method at the platform. Platform-funded spend is capped by the ceilings you configure and reconciled daily.

Ask for the sandbox before you ask for a contract.

Get a sandbox tenancySee pricing