Any Guardrails on profile Access(entities endpoint) API using via programmatically | Community
Skip to main content
R
ReshmikaPu
Level 2
June 29, 2026
Question

Any Guardrails on profile Access(entities endpoint) API using via programmatically

  • June 29, 2026
  • 1 reply
  • 0 views

Hi Community ,
​@abhi_tiwa_19 , ​@DavidRoss91 , ​@bjoern__koth , ​@Devyendar , ​@RiteshGA ​@DineshK 

We have  multiple events are generated from the source, we plan to ingest only a specific event. To achieve this, we intend to use the Profile Access API to verify whether a particular transaction event already exists for a profile in AEP.

If the transaction event is not present based on the Profile API response, the event will then be ingested into AEP via the HTTP Streaming Endpoint.

Reference:
https://experienceleague.adobe.com/en/docs/experience-platform/profile/api/entities
https://developer.adobe.com/experience-platform-apis/references/profile#operation/retrieveEntity

Additionally, are there any guardrails, soft limits, or hard limits associated with the usage of this API endpoint?
Any suggestions would be appreciated 

Thank You 
Reshmika

1 reply

DavidRoss91
Community Advisor
DavidRoss91Community Advisor
Community Advisor
June 29, 2026

Hi ​@ReshmikaPu 

When using the Profile Service API, there is the possibility of recently ingested events not being queryable right away in this case since you are looking at the profile store. It might make more sense to handle your deduplication of events outside of platform and then deciding what to bring in post that review 

R
ReshmikaPuAuthor
Level 2
June 29, 2026

​@DavidRoss91  Since we are receiving more than 20 events for a single transaction, we want to ensure that only one event is ingested. To achieve this, we are considering using the Profile Access(entities)  API to validate the current event status in AEP before ingestion.

In this approach, could you please advise if there would be any latency involved when using the API, and whether there are any implications related to API soft limits?

From a general standpoint, when using API-based validation before ingestion, are there any potential performance bottlenecks or limitations to consider?

Would you recommend this as a best practice, or is it more efficient to handle such checks within the source systems and then do Ingestion 

Terms & ConditionsAccessibility statement

Loading footer...