Get My pass_3_probe_entity List

Get My pass_3_probe_entity List.

Pass-3 probe entity

Property List:

• name: Name
• amount: Amount

MethodRouting settings example:

<details>

{
  "is_bank_id_exact_match":false,
  "method_name":"dynamicEntityProcess",
  "connector_name":"rest_vMar2019",
  "bank_id_pattern":".*",
  "parameters":[
    {
        "key":"entityName",
        "value":"pass_3_probe_entity"
    }
    {
        "key":"url",
        "value":"http://mydomain.com/xxx"
    }
  ]
}

</details>

User Authentication is Required. The User must be logged in. The Application must also be authenticated.

With a Consent: the consent user may use this endpoint only if the Consent lists this entity in my_resources.personal_dynamic_entities with the needed action (read for GET, write otherwise); rows written with a Consent belong to the User who granted it.

Filtering, sorting and pagination on the list endpoint:

(no fields on this entity are declared indexed, so only the legacy bare-parameter filter below is available.)

• Filter: ?obp_filter[FIELD]=OP:VALUE. Operators: eq, ne, in, lt, gt, le, ge, between, like, is_null, not_set. in / between take comma-separated values; is_null / not_set take no value. Repeat the same key to AND several constraints on one field. e.g. ?obp_filter[status]=eq:active&obp_filter[amount]=between:10,100 or ?obp_filter[closed_date]=not_set
• Legacy filter (still supported): bare field parameters, e.g. ?name=James%20Brown&number=123.456&number=11.11 filters by name == "James Brown" && (number == 123.456 || number == 11.11).
• Sort: ?obp_sort_by=FIELD[,FIELD2]&obp_sort_direction=ASC|DESC.
• Paginate: ?obp_limit=20&obp_offset=40.

Filtering, sorting, pagination and is_null / not_set work on every deployment (no special backend required).

One-hop joins (EXISTS / NOT EXISTS) — filter this entity by a condition on a related entity linked through a declared reference: field:

• ?obp_exists[RelatedEntity] — keep rows that have at least one related RelatedEntity.
• ?obp_exists[RelatedEntity]=filter[FIELD]=eq:VALUE — ...that have at least one matching the predicate.
• ?obp_not_exists[RelatedEntity] — keep rows with NO related RelatedEntity at all.
• ?obp_not_exists[RelatedEntity]=filter[FIELD]=eq:VALUE — ...with no related RelatedEntity matching the predicate (this includes rows that have no related RelatedEntity).
• If two entities are linked by more than one reference, disambiguate the edge with via:, e.g. ?obp_exists[RelatedEntity]=via:buyer_ref;filter[status]=eq:signed.

The nested filter[...] reuses the operator grammar above. Mind the distinction: obp_not_exists[X]=filter[flag]=eq:true (no related X with flag=true — includes rows with no X) is not the same as obp_exists[X]=filter[flag]=ne:true (has a related X with flag≠true — excludes rows with no X).

Only a field typed reference:<Entity> and declared indexed: true forms a join edge; a plain string field holding ids is not joinable.

Joins require the SQL projection backend (dynamic_entity.indexing.backend=auto on Postgres or SQL Server) with the involved fields indexed and ready. On an in-memory deployment a join query returns 400 (OBP-09022); while an index is still building it returns 409. The plain filter / sort / paginate / is_null / not_set features above do not need the projection backend.