Mymip Be MIP REST API
★ Only Publicly Available OpenAPI DocumentData EnrichmentContact EnrichmentapiKey18 EndpointsREST
For Agents
Add, search, and enrich Belgian contact records and pull reference data using a token query parameter against the MIP REST API.
Use for: I need to add a new contact to MIP, Search MIP for contacts by name and country, Retrieve a specific contact's full record, Find the indicator types supported by MIP
Not supported: Does not handle email delivery, marketing campaigns, or sales pipeline tracking - use for Belgian contact data add, search, and reference-vocabulary lookup only.
Jentic publishes the only available OpenAPI specification for MIP REST API, keeping it validated and agent-ready. MIP is a Belgian contact and reference data platform. The REST API exposes endpoints for adding contact data (queued and transactional), retrieving a contact, looking up indicators and URNs, searching contacts, and pulling reference data such as countries, genders, languages, indicator types, attribute codes, attribute types, legal forms, and unique ID codes. Authentication uses a token query parameter on api.mymip.be/RestAPI; the suffixes _q and _t denote queued and transactional variants of write operations.
Install Jentic One Beta
Connect the MIP REST API to your agent
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the MIP REST API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.
Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.
1
Step 1: Jentic One Host machine
# On the machine that will host your Jentic One instance:
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fmymip.be%2Fmymip" | sh2
Step 2: Agent machine
# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fmymip.be%2Fmymip" | sh
jentic register # connects your agent to your Jentic One instanceJentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.
Capabilities
What an agent can do with MIP REST API.
Add new contact data either transactionally via /AddContactData_t or queued via /AddContactData_q for high-volume ingestion
Search the MIP contact graph via GET /Search_t with structured query parameters
Retrieve a specific contact and its attributes via GET /GetContact_t
Inspect indicators and URN identifiers attached to a contact via /GetIndicators_t and /GetURNs_t
Look up reference data - countries, genders, languages, indicator types, legal forms, and unique ID codes - for normalising upstream data
Fetch attribute codes and types for individuals, relations (relen), and social entities to validate payloads before write
Use Cases
Patterns agents use MIP REST API for, with concrete tasks.
★ Reference Data Validation Before Write
Validate payload values against MIP's reference vocabulary before calling /AddContactData_t. The integration calls /RefCountries_t, /RefGenders_t, /RefLanguages_t, and /RefLegalFormCodes_t to build a local cache of valid codes, then rejects malformed payloads upstream. This avoids round-trip rejections and produces clean writes to the MIP contact graph.
Cache GET /RefCountries_t, /RefGenders_t, /RefLanguages_t, and /RefLegalFormCodes_t at startup, then validate every incoming contact payload against the cached codes.
Contact Search and Lookup
Find existing MIP contacts before creating duplicates by calling GET /Search_t with structured parameters. The integration returns the matched contact identifiers, then fetches the full record via GET /GetContact_t for downstream display. /GetIndicators_t and /GetURNs_t supplement with the indicator and identifier metadata attached to the contact.
Call GET /Search_t with the candidate name, then GET /GetContact_t for the top match, and GET /GetIndicators_t to inspect attached indicators.
High-Volume Queued Ingestion
Push high-volume contact updates to MIP via the queued endpoint POST /AddContactData_q to avoid blocking on per-call processing. The transactional sibling /AddContactData_t is reserved for time-sensitive single writes. This split lets the integration process large batches asynchronously while still using transactional writes for user-driven flows.
Iterate through the daily contact batch and POST each record to /AddContactData_q, while routing user-driven single writes through POST /AddContactData_t.
Attribute Schema Discovery
Discover the valid attribute codes and types for individual, relen (relations between entities), and social entries by calling /RefAttributeCodes4Individual_t, /RefAttributeCodes4Relen_t, and /RefAttributeCodes4Social_t together with their corresponding /RefAttributeTypes endpoints. This builds a self-describing schema for the consuming application without hard-coding MIP's vocabulary.
Call all six /RefAttributeCodes4* and /RefAttributeTypes4* endpoints and merge the responses into a single attribute dictionary keyed by entity type.
AI Agent Belgian Contact Concierge
An AI agent acts as a contact-management assistant for a Belgian organisation. It searches Jentic for MIP operations, loads the search and add-contact schemas, validates the payload against the reference endpoints, and writes via /AddContactData_t. Jentic isolates the token query parameter so the agent never sees the raw secret in URLs or logs.
Search Jentic for 'add a contact to MIP', validate the payload against /RefCountries_t and /RefLegalFormCodes_t, then POST /AddContactData_t.
Key Endpoints
18 endpoints — jentic publishes the only available openapi specification for mip rest api, keeping it validated and agent-ready.
METHOD
PATH
DESCRIPTION
POST
/AddContactData_t
Add contact data transactionally
POST
/AddContactData_q
Queue contact data for asynchronous processing
GET
/GetContact_t
Retrieve a contact record
GET
/Search_t
Search the contact graph
GET
/GetIndicators_t
Get indicators attached to a contact
GET
/GetURNs_t
Get URN identifiers attached to a contact
GET
/RefCountries_t
List valid countries
GET
/RefLegalFormCodes_t
List valid legal form codes
POST
/AddContactData_t
Add contact data transactionally
POST
/AddContactData_q
Queue contact data for asynchronous processing
GET
/GetContact_t
Retrieve a contact record
GET
/Search_t
Search the contact graph
GET
/GetIndicators_t
Get indicators attached to a contact
GET
/GetURNs_t
Get URN identifiers attached to a contact
GET
/RefCountries_t
List valid countries
GET
/RefLegalFormCodes_t
List valid legal form codes
Why Jentic?
What agents get from Jentic-routed access to this vendor.
Setup
Wiring MIP by hand means holding its API token, appending it to every request against api.mymip.be/RestAPI, and mapping the Belgian contact and reference-vocabulary calls yourself. Through Jentic you install once, import MIP from the API Directory, store the token once, and your agent calls it.
Permission scoping
MIP addresses contacts through request parameters rather than a resource id in the URL path, so scope the agent to the operations it needs, such as searching contacts or reading reference vocabularies, and leave write operations like adding contact data out of the allowed set unless you include them.
Credential isolation
Your MIP token is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
Intent-based discovery
Agents search Jentic by intent such as 'search contacts in MIP' or 'look up a legal-form code', and Jentic returns the matching MIP operation with its input schema so the agent calls the right endpoint without browsing the reference docs.
Related APIs
Alternatives and complements available in the Jentic catalogue.
FAQs
Specific to using MIP REST API through Jentic.
Why is there no official OpenAPI spec for MIP REST API?
MIP does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call MIP REST API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.
What authentication does the MIP REST API use?
The MIP REST API authenticates with a `token` query parameter on every request. Through Jentic, the token is stored in the encrypted vault and appended to the URL at execution time, so agent code and prompts never include the raw secret in logs or URL strings.
What is the difference between /AddContactData_q and /AddContactData_t?
The `_q` suffix denotes the queued variant - the request is accepted and processed asynchronously, suited to high-volume batch ingestion. The `_t` suffix denotes the transactional variant - the request is processed synchronously and is suited to user-driven, time-sensitive writes.
How do I search for contacts through Jentic?
Search Jentic for 'search contacts in MIP', load the GET /Search_t schema, and execute it with the search parameters. Chain GET /GetContact_t for the top match to retrieve the full contact record in the same agent run.
Which reference data endpoints does MIP expose?
MIP exposes reference endpoints for countries (/RefCountries_t), genders (/RefGenders_t), languages (/RefLanguages_t), indicator types (/RefIndicators_t), legal forms (/RefLegalFormCodes_t), unique ID codes (/RefUniqueIDCodes_t), and per-entity attribute codes and types for individuals, relen, and social entries.
What are the rate limits for the MIP REST API?
The published spec does not document explicit rate limits. Treat the API as throttled in production, prefer the /AddContactData_q queued endpoint for bulk writes, and contact MIP support for account-specific limits before running large imports.
Can I limit what my agent is allowed to do with the MIP REST API?
Yes. Because you run Jentic One yourself, your own rules decide which MIP operations and credentials the agent can use, so you allow only the endpoints a given task needs. MIP addresses contacts through request parameters rather than a resource id in the URL path, so you scope by operation: grant read-only calls such as GET /Search_t, GET /GetContact_t, and the reference lookups like /RefCountries_t and /RefLegalFormCodes_t, while leaving write operations such as POST /AddContactData_t and /AddContactData_q out of the allowed set unless you include them. This keeps an agent that only needs to search or validate contacts from ever adding or queuing new records.
GET STARTED