[Laravel] DTO properties ignored by serializer Groups in both output (provider) and input (processor)

[shahzaibtariqbutt]

API Platform version(s) affected: 4.1.20

Description
When returning a DTO from a custom provider in API Platform for Laravel, none of the DTO’s properties are exposed in the JSON-LD response, even though they are annotated with #[Groups] matching the normalizationContext of the operation.

How to reproduce

#[ApiResource(
    operations: [
        new GetCollection(
            uriTemplate: '/slots/pickup',
            provider: SlotPickupProvider::class,
            output: SlotDto::class,
            normalizationContext: [
                'groups' => [
                    'read:pickup',
                ],
            ],
        ),
    ]
)]
#[ApiProperty(
    property: 'id',
    serialize: new Groups([
        'read:pickup',
    ]),
)]
class Slot extends Model {}

final readonly class SlotDto
{
    public function __construct(
        #[Groups(['read:pickup'])]
        public CarbonImmutable $date,

        /**
         * @var Slot[]
         */
        #[Groups(['read:pickup'])]
        public array $slots,
    ) {
    }
}

Expected Result

{
  "@context": "/contexts/Slot",
  "@id": "/slots/pickup",
  "@type": "Collection",
  "totalItems": 10,
  "member": [
    {
      "@id": "/.well-known/genid/e1f4019f1928036caeca",
      "@type": "SlotDto",
      "date": "2025-08-10",
      "slots": [
        { "id": "id_of_slot", "start_time": "08:00", "end_time": "10:00" }
      ]
    }
  ]
}

Actual Result

{
  "@context": "/contexts/Slot",
  "@id": "/slots/pickup",
  "@type": "Collection",
  "totalItems": 10,
  "member": [
    {
      "@id": "/.well-known/genid/e1f4019f1928036caeca",
      "@type": "SlotDto"
      // no properties serialized
    }
  ]
}

Notes:
The DTO is returned directly from the provider.
The properties have correct #[Groups] annotations matching the normalizationContext.
Works fine when returning an Eloquent model, but fails for DTOs.

[shahzaibtariqbutt]

@soyuka Hi,
Additional symptom (POST with DTO as input — denormalization fails)

API Platform: 4.1.21 (Laravel)

Alongside the provider/output case described above, I’m seeing the inverse on input: when using a DTO as input on a Post operation, the DTO instance reaching the custom processor is correctly typed but all properties are null, despite matching #[Groups] and denormalizationContext.

// In Order.php
#[ApiResource(operations: [
    new Post(
        input: OrderInput::class,
        rules: OrderPostRequest::class, // custom validation hook (project-specific)
        processor: OrderCreateProcessor::class,
        denormalizationContext: ['groups' => ['order:write']],
    ),
])]

// In Processor
final class OrderCreateProcessor implements ProcessorInterface
{
    public function process(mixed $data, Operation $operation, array $uriVariables = [], array $context = []): Order
    {
        \Webmozart\Assert\Assert::isInstanceOf($data, OrderInput::class);
        dd($data); // instance of OrderInput, but all properties are null
    }
}

// In Dto
use Symfony\Component\Serializer\Annotation as Serializer;

final class OrderInput
{
    #[Serializer\Groups(['order:write'])]
    public ?string $pickupDate = null;

    #[Serializer\Groups(['order:write'])]
    public ?string $pickupSlotId = null;
}


// Request Payload
{
  "pickupDate": "2024-10-24",
  "pickupSlotId": "e9f1b1a2-...-..."
}

Expected
API Platform denormalizes the JSON body into OrderInput, populating pickupDate and pickupSlotId (per denormalizationContext groups) before invoking the processor.

Actual
$data is an OrderInput, but every property remains null in OrderCreateProcessor::process().

[soyuka]

You should avoid using input/output when possible. Not sure why you're getting null in properties though to debug its at https://github.com/api-platform/core/blob/main/src/State/Processor/SerializeProcessor.php#L82.

[shahzaibtariqbutt]

@soyuka I can confirm there's still some issues with dtos.

For some reason, when we use a DTO as input, the properties are now being de-normalized correctly. But when we use a DTO as output, none of its properties are exposed in the JSON-LD response—even though the properties are annotated with #[Groups] and the operation has the correct normalizationContext. It behaves as if the groups were ignored.

How to reproduce

Define an operation with output: MyDto::class and set normalizationContext to use a group.

Add #[Groups([...])] to the DTO properties.

Return the DTO instance from the processor/provider.

Expected:

{
  "@type": "MyDto",
  "success": true,
  "redirectionUrl": "https://…",
  "message": ""
}

Actual:

{
  "@type": "MyDto"
  // no properties serialized
}

This mirrors what I originally reported: DTOs used for input/output with groups don’t behave consistently. Input side seems fixed, but output side is still broken.

This is my case

new Post(
            uriTemplate: '/payment-methods',
            rules: PaymentMethodPostRequest::class,
            input: PaymentCreateInput::class,
            output: PaymentCreateOutput::class,
            processor: PaymentMethodCreateProcessor::class,
            normalizationContext: [
                'groups' => [
                    'PaymentMethod:V',
                ]
            ],
            denormalizationContext: [
                'groups' => [
                    'PaymentMethod:W',
                ],
            ]
        ),

final class PaymentCreateOutput
{
    public function __construct(
        #[Serializer\Groups([
            'PaymentMethod:V',
        ])]
        public bool $success,
        #[Serializer\Groups([
            'PaymentMethod:V',
        ])]
        public ?string $redirectionUrl,
        #[Serializer\Groups([
            'PaymentMethod:V',
        ])]
        public string $message = '',
    ) {
    }
}

[soyuka]

there's no reason to use both an input and an output, use your Resource as output with an input, output only usage should be output: false.

[shahzaibtariqbutt]

👋 @soyuka

I agree that we should avoid using both because it increases complexity. However, I can confirm there’s an issue when using a custom DTO as input in the model:

• In my case, I don’t need any output, but I do need a custom DTO as input. (version: 4.1.25)
• The problem is that inside the processor, $data->items is always an empty array, even though I’m sending valid data in the request.
• Interestingly, if I move the #[ApiResource()] annotation to the OrderItemBulkApprovalInput DTO itself, it starts working fine.

Example DTOs

final readonly class OrderItemBulkApprovalInput
{
    /**
     * @param OrderItemBulkApprovalDecision[] $items
     */
    public function __construct(
        #[Serializer\Groups(['OrderItem:W$BulkApproval'])]
        #[Assert\Count(min: 1, max: 50)]
        public array $items,
    ) {
    }
}

final readonly class OrderItemBulkApprovalDecision
{
    public function __construct(
        #[Serializer\Groups(['OrderItem:W$BulkApproval'])]
        public string $orderItemId,

        #[Serializer\Groups(['OrderItem:W$BulkApproval'])]
        public bool $isApproved,
    ) {
    }
}

Resource Definition in Order.php Model

new Post(
    middleware: ['auth:admin_or_owner'],
    uriTemplate: '/orders/{id}/bulk-approval',
    input: OrderItemBulkApprovalInput::class,
    processor: OrderItemBulkApprovalProcessor::class,
    denormalizationContext: [
        'groups' => ['OrderItem:W$BulkApproval'],
    ],
    status: 200,
),

Test Call

$resp = $this->request('POST', "/orders/{$order->id}/bulk-approval", [
    'items' => [
        [
            'orderItemId' => $first->id,
            'isApproved' => true,
        ],
        [
            'orderItemId' => $second->id,
            'isApproved' => false,
        ],
        [
            'orderItemId' => $third->id,
            'isApproved' => false,
        ],
    ],
]);

[soyuka]

good catch thanks for the report!