A Sitefinity dynamic module endpoint may return an empty response in one environment while the same content is returned in another environment or through a similar endpoint with a numeric suffix.

Typical symptom pattern:

• The unsuffixed endpoint returns HTTP 200 and a valid OData payload such as { "@odata.context": "...", "value": [] }
• A suffixed endpoint for the same apparent content type, such as /api/default/exampleitems1, returns the expected items
• One environment works as expected, while another appears empty for the original endpoint name

Common customer wording that should remain searchable:

• "The production API is returning an empty response, while the staging API is working as expected."
• "Production API returning empty response for PostLogin modules"
• "the modules below are still not showing/returning data in Production"
• "when I use the modified API/content type names, they are returning the data correctly"
• "Could you please check why the original API names are returning empty data in Production, while the modified names are working?"
• "Could you also please confirm whether the API/content type names have been changed in Production?"
• "If there is any supported Sitefinity configuration or approach that would allow us to rename or align the API endpoints in both environments while preserving the existing data"

This article applies when duplicate active dynamic content types exist in the same environment and share the same developer name, typically after modules were created independently in different environments and later synchronized.

The OData entity-set name for a dynamic content type is computed at runtime from the content type developer name by lowercasing it and pluralizing it. The entity-set name is not stored as a persisted value for the dynamic type.

If multiple active dynamic content types resolve to the same entity-set name, Sitefinity keeps all of them addressable by appending numeric suffixes to the collisions after the first. Which type keeps the unsuffixed endpoint depends on runtime enumeration order and should not be treated as stable.

Because only active modules contribute to the service contract set, an active duplicate type can occupy the unsuffixed endpoint while the type that actually contains the content is exposed under a suffixed endpoint.

Use the active-module state to remove the collision without deleting data.

1. Go to Administration > Modules and Services.
2. Locate the duplicate dynamic module that does not hold the expected content.
3. Confirm that its content types share the same developer name as the module that does hold the content.
4. Set the duplicate module to Deactivate.
5. Do not delete the module.
6. Do not move data.
7. Test the unsuffixed endpoint again, for example /api/default/{entityset}?sf_culture=en.

Expected result:

• The unsuffixed endpoint returns the content that was previously available only through the suffixed endpoint.
• The change is reversible by reactivating the module if needed.