Numerology Compatibility: Why a Match Is Read Both Ways

Numerology compatibility takes two birth dates and asks how the two people's numbers get along. Our API finds each person's mulank, the number of the birth day. It also finds the bhagyank, the number of the whole birth date. Each of those numbers belongs to a planet. The match then checks how each planet treats the other person's planet.

That treatment is one-sided. In the classical table of planet friendships, Jupiter counts Venus as an enemy. Venus sees Jupiter as neutral. For that reason the API reads four one-way links. Two run between the mulanks, one in each direction. Two more run between the bhagyanks. One stated rule turns the four links into one outcome. Nothing is scored.

Take John Doe, born Aug 15, 1990. Both his mulank and his bhagyank come to 6. Jane Doe's birth date is Mar 22, 1992, which gives mulank 4 and bhagyank 1. Between the mulanks, both links are friendly. Between the bhagyanks, both are unfriendly. A friendly link plus an unfriendly one gives "Mixed".

Reading both ways keeps the result fair to both people. A chart read from one side can call a pair neutral for one user and not a good fit for the other. All four links give one answer. It does not change if the two people trade places.

Numerology compatibility for John and Jane, link by link

We sent John and Jane to POST /v1/compatibility on October 17, 2026. This route matches two people. It takes one birth date for each person, under a and b, and nothing else.

First come the four numbers. John's birth day is the 15th, and 1 + 5 gives his mulank of 6. The eight digits of his date add up to 33, and 3 + 3 gives his bhagyank of 6. Jane was born on the 22nd, and 2 + 2 gives her mulank of 4. Her date adds up to 28, then 10, then 1. Both sums appear digit by digit in our mulank, bhagyank and name number guide. To try another date, use our free numerology calculator.

Then come the links. Each one asks how the first number's planet counts the second number's planet.

Two friendly links and two unfriendly ones meet the rule for mixed, labelled "Mixed". For this pair, each link agrees with its mirror. Venus and Saturn count each other as friends. The Sun and Venus count each other as enemies. That is a feature of these four numbers, not a rule. The next sections show pairs where the two sides split.

Number friends, in plain words

Indian numerology pairs each number from 1 to 9 with a planet. The list runs 1 Sun, 2 Moon, 3 Jupiter, 4 Rahu, 5 Mercury, 6 Venus, 7 Ketu, 8 Saturn and 9 Mars. Our number planets entry sets out that order. So a pair of numbers is only as friendly as its planets.

Our API keeps no list of good pairs. It uses the classical table of natural friendship between planets, taken from Indian astrology. In it, each planet sorts the others into friends, neutrals and enemies. The table answers one question at a time: how does this planet see that one? The answer in reverse can differ.

Two pairs show it. The Moon counts Mercury as a friend, yet Mercury counts the Moon as an enemy. Jupiter counts Venus as an enemy, yet Venus counts Jupiter as neutral. A number always meets itself as the same number, and the rule treats that like a friend.

Rahu (4) and Ketu (7) mark the two spots where the Moon's orbit cuts across the Sun's path. They get no row of their own in the table. By the usual convention, Rahu borrows Saturn's row, and Ketu borrows the row of Mars. Each link that used a stand-in names it in via. Both of Jane's mulank links carry "via": ["Rahu"].

Our number checks use the same friendships, but only one way. A phone number is read from its owner's side, as our post on mobile number numerology shows. A phone has no view of its owner. A person does, so a match between two people reads both directions.

How John's 6 meets each number, both ways

To see the full picture, we matched John with 9 partners, born Jul 1 to Jul 9, 1991. Each of those dates gives the same number twice. The partner born Jul 3, 1991, has mulank 3 and bhagyank 3, for example. So each row shows one number seen from both sides.

Four partners came back as a good fit, 2 as neutral and 3 as not a good fit. In rows 2 and 3, the two sides disagree. Those are the rows where a one-way chart misleads.

No row came back mixed. A mixed result needs a friendly link and an unfriendly one in the same pair. Here both of John's numbers are 6, and each partner's two numbers match too. Jane's two numbers differ, which is how she and John landed on Mixed.

Why a one-way chart gives two answers

A "compatible numbers" chart is a list for each number, read from that number's side. The two mulank pages we read for this post each print one. Our API returns lists like that too. The list for 6 has 4, 5, 6 and 8 under friendly, 3, 7 and 9 under neutral, and 1 and 2 under unfriendly. For 3, the friendly numbers are 1, 2, 3, 7 and 9. The neutral ones are 4 and 8, and the unfriendly ones are 5 and 6.

Now put John beside the partner born Jul 3, 1991. John's list calls 3 neutral. The partner's list calls 6 unfriendly. Build the match on one list, and the result depends on who opened the screen. John sees Neutral. His match sees Not a good fit. Both are looking at the same two birth dates.

Read both ways, the four links are neutral, unfriendly, neutral and unfriendly. Two unfriendly links, with no friendly link to balance them, make the outcome difficult. Its label is "Not a good fit". We sent this pair in both orders. Both answers said Not a good fit, and only the who labels traded places. John and Jane did the same: swapped, they still came back Mixed. The order of a and b never changes the outcome.

Charts on other sites do not always agree with the planet table. Some mulank pages list 3 and 6 as a good pair. Our API calls that pair Not a good fit, since Jupiter sees Venus as an enemy. So name the rule on your screen. A user who brings a chart from elsewhere can then see why yours differs.

Four outcomes and no score

The rule has four cases, and none of them is weighted.

The answer holds no percent and no points. The reason is written into our code. Count each friend as plus 1 and each enemy as minus 1, and John and Jane score 0. A pair with four neutral links also scores 0. Those pairs say two different things, and one number would hide the difference.

Other tools do score. One calculator we read weights the life path at 50%, the expression number at 30% and the soul urge at 20%. It then shows one score from 0 to 100. Another looks up two life path numbers in a fixed table. Those are Western numbers, and two of them are worked out from the name. Our route reads the Indian numbers and needs no name. Our post on Indian vs Western numerology helps you pick the set your users expect.

So do not turn the outcome into a percent. Any percent on the screen would be your app's number, not the API's. Nobody could trace it back to a rule.

What the answer holds

The request below sends the pair from the docs.

John Doe, born Aug 15, 1990 (a), and Jane Doe, born Mar 22, 1992 (b).

curl -X POST "https://apiforastrology.com/api/numerology/v1/compatibility" \
  -H "Authorization: Bearer $ASTROLOGY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"a":{"birth_date":"1990-08-15"},"b":{"birth_date":"1992-03-22"}}'

The answer for John and Jane, trimmed. The full answer adds `from_name`, the `reading` and the `not_claimed` line.

{
  "a": { "birth_date": "1990-08-15", "mulank": 6, "bhagyank": 6, "mulank_planet": "Venus" },
  "b": { "birth_date": "1992-03-22", "mulank": 4, "bhagyank": 1, "mulank_planet": "Rahu" },
  "links": [
    { "who": "a_to_b", "from": "mulank", "from_number": 6, "to_number": 4, "relation": "friend", "relation_name": "friendly", "via": ["Rahu"] },
    { "who": "b_to_a", "from": "mulank", "from_number": 4, "to_number": 6, "relation": "friend", "relation_name": "friendly", "via": ["Rahu"] },
    { "who": "a_to_b", "from": "bhagyank", "from_number": 6, "to_number": 1, "relation": "enemy", "relation_name": "unfriendly", "via": [] },
    { "who": "b_to_a", "from": "bhagyank", "from_number": 1, "to_number": 6, "relation": "enemy", "relation_name": "unfriendly", "via": [] }
  ],
  "outcome": "mixed",
  "outcome_name": "Mixed"
}

Each field has a job. The who field gives the direction of a link, a_to_b or b_to_a. The relation field is a code for your logic: same, friend, neutral or enemy. The relation_name field is the word to print: same number, friendly, neutral or unfriendly. The outcome works the same way, with the code in outcome and the label in outcome_name.

Add lang=hi to get Hindi. Mixed then comes back as मिला-जुला, and friendly as मित्र (फ़्रेंडली). Only the words change. Codes such as outcome keep their English values, so one set of app logic serves both languages. With detail=expanded, the reading grows from 88 characters to 369 for this pair.

We also sent John's and Jane's names beside their dates. The answer did not change at all. Two people with the same birth date, such as twins, get four same links and Good fit.

Bad input gets a clear refusal. A missing person or a date that does not exist, such as Feb 30, gets a 422 answer, with invalid_input as its code. The field value names the part that failed, such as b or b.birth_date. Each call reads one pair and uses 1 reading credit.

Check the full field list. Our numerology compatibility API page lists every field and the rule behind the outcome.

One match screen, top to bottom

Here is one way to lay out a match, using only what the API returns. Our numerology app development guide lists it among an app's six screens.

Lead with the label and the reading. Print outcome_name in large type, with the reading under it. Use the API's words. Keep the codes enemy and difficult in your logic and off the screen.

Show the four links as the reason. Under the label, list each link in a plain line, such as "John's birth day number sees Jane's as friendly." Show all four, so each person sees their own side. A user who wonders why the match came out Mixed can read it right there.

Keep the wording calm. Plan for every label. Our API's tests run a wide sample of birth-date pairs. They fail if any one outcome covers 80% or more. In our sweep, 3 of John's 9 partners came back Not a good fit. The API's own line for that outcome stays gentle: "Your numbers do not get along easily. You may see things very differently, so talk things through." Keep that tone in any text you add. Skip red badges and warning icons.

Put the `not_claimed` line beside it. Every answer ends with it, and it reminds the user that numbers point to leanings and do not fix what happens. A number match gives two people something to talk about. It does not decide for them.

Send the pair in any order. Put the viewer in a and the match in b, or the other way around. The outcome is the same, so both users always see one answer.

Ask for the birth date only. A member who does not know a birth time can still be matched.

Next to a kundli match. The Astrology API's kundli matching compares two kundlis, or birth charts, and scores them out of 36 points. That match also needs birth times and places. Our guide to kundli matching on matrimony sites covers that screen. For a whole matrimony product, see the numerology for matrimony platforms page.

New to number friends? The friendly numbers entry in our glossary explains the idea in a few lines, with John Doe's lists.

The short version

Numerology compatibility reads two birth dates as four one-way links. Each person's mulank looks at the other's, and so does each bhagyank. One rule turns those links into Good fit, Neutral, Mixed or Not a good fit, with no score. Read from one side, a chart can tell two users two different stories. Read both ways, the pair gets one answer, whichever person comes first in the request.