## TL;DR

For "Invalid request body.": the serialized request body was missing the category field entirely: {"name":"dd_intro_2","language":"en","allowCategoryChange":false,"structure":{...}}. Do not instantiate the base WhatsAppTemplatePublicApiRequest: in 6.x you must use the concrete category subclass, e.g. new WhatsAppDefaultMarketingTemplatePublicApiRequest for MARKETING templates (or the UTILITY / AUTHENTICATION variants), which serializes the category field correctly.

```text
Invalid request body.
```

## When to use

You are seeing this: After upgrading infobip-api-php-client to 6.2.1, creating a registered WhatsApp template via createWhatsAppTemplateRequest failed with BAD_REQUEST ("Invalid request body."). Use this skill when you run into "infobip-api-php-client: createWhatsAppTemplate fails with Invalid request body (category missing)".

## When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

## Versions

Versions mentioned in the source: 6.2.1. If you are on something much newer or older, the details may have shifted.

## What's going on

After upgrading infobip-api-php-client to 6.2.1, creating a registered WhatsApp template via createWhatsAppTemplateRequest failed with BAD_REQUEST ("Invalid request body."). The serialized request body was missing the category field entirely: {"name":"dd_intro_2","language":"en","allowCategoryChange":false,"structure":{...}}. The DiscriminatorMap on WhatsAppTemplatePublicApiRequest used category to pick the concrete subclass, and instantiating the base WhatsAppTemplatePublicApiRequest directly meant the category never got serialized.

## The verified fix

Do not instantiate the base WhatsAppTemplatePublicApiRequest: in 6.x you must use the concrete category subclass, e.g. new WhatsAppDefaultMarketingTemplatePublicApiRequest for MARKETING templates (or the UTILITY / AUTHENTICATION variants), which serializes the category field correctly. The reporter switched to the subclass and the Invalid request body error went away; the maintainers' test fixtures confirm the serialized body includes "category": "MARKETING".

## How to use this

Take the question above and check if it matches what you're seeing. If it does, work through the verified fix step by step. Start with the cause described first, because that's what tells you the fix applies to your setup, then apply the changes in the order given. Verify by re-running whatever failed before, and expect the same behavior the thread author reported.