Error 100: Invalid Parameter

Error 100 is the WhatsApp Cloud API's general-purpose validation failure: something in the request is malformed, and Meta rejects it before attempting delivery. It is almost always a developer-facing error rather than something end users of VGraple CRM's own screens encounter, since the product normalises the common causes automatically.

Symptom

An API call fails with error 100, and Meta's own title reads close to "Invalid parameter." The response typically names the specific field that failed, though the level of detail varies by which underlying condition triggered it. This is the first error many integrations hit, since it is the general validation gate every request passes through, and it can stem from several genuinely different causes that share only the same error code.

Why it happens

The most common cause by a wide margin is a phone number in the wrong format. The Cloud API requires numbers in international format, digits only, with no leading plus sign, no spaces, and no leading zero, which is stricter than what a person would type into the WhatsApp mobile app to message someone directly. A second common cause is a media reference problem: a media URL Meta's servers cannot fetch publicly (a private, authentication-gated, or redirecting URL), rather than a media ID from an actual upload. A third is a template component supplied in the wrong order or shape, a header component where the template does not have one, or a button parameter formatted incorrectly. Beyond these three, error 100 also covers more general cases: an unknown or misspelled field name in the request body, or a value that exceeds an allowed length limit for that field.

Fix

1. Read the specific field Meta's response names, if one is given. Error 100 covers several distinct causes, and the field name usually narrows it immediately rather than requiring guesswork.
2. For a phone number issue, strip the number to digits only, in international format, with no plus sign, no spaces, and no leading zero. A number stored as "+91 98989 89898" needs to become "919898989898" for the API.
3. For a media issue, upload the file first and reference it by media ID rather than a raw URL. If a URL must be used directly, confirm it is publicly fetchable with no authentication and does not redirect.
4. For a template component issue, compare the request's component order and shape against the template's actual approved structure in the template builder, header, body, footer, buttons, in that order, with only the components the template actually has.
5. For an unknown-field or length error, check the request body against the current API reference for that endpoint, since a field name typo or an outdated integration built against an older version of the API is a common source.

How VGraple CRM handles it automatically

Phone numbers are normalised to the correct international digits-only format before every send that originates from VGraple CRM's own product screens, broadcasts, the inbox, sequences and flows, so a contact's number stored in any reasonable human format is converted correctly without the sender needing to think about it. Media sent from these same screens is uploaded to Meta first and referenced by media ID, never sent as a raw external URL, which avoids the fetchability problem entirely. Template payloads built from the product's own screens are constructed directly from the approved template's live structure, so a component-order or shape mismatch cannot occur from that path. Because of this, error 100 is uncommon when using the product as intended and appears almost exclusively on direct REST API integrations that build their own request payloads; for those, API responses include the field name and, where practical, an example of the expected format, rather than a bare error code with no guidance.

Prevention

For anyone building against the REST API directly, normalising phone numbers to E.164-style digits-only format at the point of storage, not just before sending, avoids this entire class of error and keeps phone data consistent for every other purpose too. Always upload media and reference it by ID rather than passing external URLs, even when a URL is technically reachable at the moment of testing, since URLs that work today can become private, expire, or start redirecting later. When building template payloads by hand, generate them from the template's current approved definition programmatically where possible, rather than hand-writing a payload that can silently drift out of sync after the next template edit; see errors 132000 and 132001 for what happens when a payload and a template definition disagree on variable count specifically, a closely related but distinct failure.

Does error 100 ever indicate a Meta-side problem?

Rarely. Unlike codes such as 135000 or 130429, which can reflect genuine Meta-side pacing or transient conditions, 100 is specifically a request validation failure: Meta is telling you the request itself, as constructed, does not meet its requirements. It is worth treating every 100 as a signal to fix the calling code rather than something to retry unchanged, since resending the exact same malformed request will fail identically every time, no backoff or delay changes that outcome the way it can for a genuinely transient error.