Skip to content

Browse the documentation

Token error #100 — read versus write

A healthy Conversions API token fails a read with error #100. That is normal. The same error on an events POST is not, and means something different.

updated

Conversions API tokens are write-only. A read request against the pixel object with a perfectly healthy CAPI token returns error #100, “Missing Permission” — every time, by design. So the error alone tells you nothing until you know which kind of request produced it.

The two cases

Where you saw #100 What it means
On a read (e.g. GET /{pixel-id}?fields=name) Normal. CAPI tokens cannot read. This says nothing about the token’s health.
On an events POST A real permission problem. Usually the token is bound to a different pixel, or the system user that owns it has not been given the asset.

This is why PixelCapi’s Verify button sends a Test Event rather than performing a read check. A verification built on a read would fail for every healthy token, which is a green light that can only ever be red — the opposite of useful.

Diagnosing a #100 on a POST

1. Check what the token actually carries. Meta’s access token debugger shows a token’s scopes and, importantly, which pixel it is bound to. Most #100 errors on POST turn out to be a token generated for a different dataset than the one you pasted the ID for.

2. Check which of the two setup options you used. In Events Manager, Settings → Conversions API → Set up manually offers two radios:

  • Set up with Dataset Quality API — Meta marks this “Recommended”. It adds a read scope on top of write.
  • Set up without — a plain write token.

Both can send events. If your token debugger shows only read_ads_dataset_quality and no write capability, the token was generated in a way that cannot post events, and you need to regenerate it.

3. Check the system user’s assets. If the token belongs to a Business Manager system user, that user must have the pixel assigned to it. A token can be valid, correctly scoped and still rejected because its owner has no access to that specific asset.

Do not “test” a CAPI token with a GET

It is the obvious thing to try and it produces a confident, wrong answer. Every CAPI token you own will fail a read. If a tool tells you your token is broken on that basis, the tool is broken.

While you are here

Set a Test Event Code before you paste a real token anywhere. Without one, verification and test sends go into your live reporting, and individual events cannot be deleted — they only age out of the reporting windows. See The 3-minute setup.

Was this page helpful?