Overview
The matching endpoint compares two birth profiles — traditionally an Ashtakoota-style guna comparison — and returns the components and an overall structured result. Your product decides how to present it. Examples use one sample birth, Aarav Sharma, born 1990-08-15 at 10:30 in Kolkata, and a second profile shown with placeholder values.
This is an integration walkthrough. See Documentation for the exact request body, the comparison components, and plan gates.
Sending Two Profiles
Send both births in one request. Keep each person’s input in the same shape you use for the Kundli endpoint:
curl -X POST https://horoscope.devdarsha.com/v1/matching \
-H "content-type: application/json" \
-H "x-api-key: YOUR_API_KEY" \
-d '{
"person_a": {"date":"1990-08-15","time":"10:30","city":"Kolkata"},
"person_b": {"date":"YYYY-MM-DD","time":"HH:MM","city":"CITY"}
}'Replace person_b with the second user’s real birth details at request time.
Reading the Result
The response breaks the comparison into components with individual results plus an overall summary. Surface the components so users can see what contributed to the comparison, rather than only a single number. Keep the wording factual and let users interpret the outcome themselves.
Matching uses two people’s birth data. Collect the second person’s details only with appropriate consent, keep the input server-side, and avoid storing more than your product needs.
How to Use It in a Product
Two common patterns:
- On-demand match: the user enters a second person’s birth details and sees a one-off comparison.
- Profile-to-profile: both people already have stored birth input, and you compute the comparison when they connect.
Cache a comparison against the pair of birth inputs so re-opening a match does not recompute it.
Rollout Planning
Test representative pairs in Playground, including edge-case birth times. Confirm your UI handles optional or plan-gated components, and store the X-Request-ID so a specific comparison can be traced in support.