Mobile number numerology, also called phone number numerology, adds up every digit of a phone number until one digit is left. Then it reads that digit against the owner's own numbers. Take 212 555 0147. Its digits add up to 32, and 3 + 2 gives 5. In Indian numerology, 5 belongs to Mercury.
The owner here is John Doe, born Aug 15, 1990. His mulank, the number of his birth day, is 6. So is his bhagyank, which comes from his whole birth date. Their planet is Venus, and Venus counts Mercury as a friend. So our API calls this number a good fit for John.
The math is the easy part. The input is where the answer can drift. Our API skips spaces, dashes, brackets, dots and the + sign. A zero adds nothing, so a leading 0 changes nothing. Every other digit counts, and that includes a country code. Typed as +1 212 555 0147, the same phone adds up to 33, which gives 6.
So your app decides which digits the user types. The three guides we read for this post all leave the country code out. We suggest the same: ask for the number as it is dialed inside its own country. Then show the user the digits that were counted.

Mobile number numerology, step by step
We sent John's phone to POST /v1/number on October 17, 2026. It is our API's route for one mobile, vehicle or house number. Here is the working behind its answer.
Step | What happens | John Doe's phone |
|---|---|---|
1. Keep the digits | The spaces drop out | 2, 1, 2, 5, 5, 5, 0, 1, 4, 7 |
2. Add them | 2 + 1 + 2 + 5 + 5 + 5 + 0 + 1 + 4 + 7 | 32 |
3. Reduce | Add the digits of the total: 3 + 2 | 5 |
4. Find the planet | In Indian numerology, 5 belongs to Mercury | Mercury |
5. Read it against the owner | Mulank 6 and bhagyank 6, both Venus | Good fit |
The 32 also comes back as compound, the sum as it stood before it was cut down to one digit. Our API returns it but does not read it. The compound number entry says more.
John's two numbers come from his birth date alone. His mulank is the day, 15, so 1 + 5 = 6. All eight digits of his birth date make 33 for his bhagyank, and 3 + 3 = 6. Both sums are worked in full in our explainer on the three core numbers. Our free numerology calculator finds them for any date. The phone check needs no name, so the request carries only the birth date.
Next, each of John's numbers is checked against the phone's number. Both are 6, and Venus counts Mercury as a friend. Two friendly links and no unfriendly one make a good fit. The answer adds one short line for that outcome: "This number gets along well with your own numbers. It tends to support you."
What the API keeps and what it drops
People write one phone number in many ways. We sent seven forms of John's number. All seven came back as 5.
What the user typed | Digits the API added | Total | Number |
|---|---|---|---|
212 555 0147 | 2125550147 | 32 | 5 |
2125550147 | 2125550147 | 32 | 5 |
212-555-0147 | 2125550147 | 32 | 5 |
(212) 555-0147 | 2125550147 | 32 | 5 |
212.555.0147 | 2125550147 | 32 | 5 |
0 212 555 0147 | 02125550147 | 32 | 5 |
२१२ ५५५ ०१४७ (Hindi digits) | 2125550147 | 32 | 5 |
The rule in our code fits in one line. Each digit is added, each letter is set aside, and nothing else counts. Spaces, dashes, brackets, dots and plus signs drop out with no note.
Two rows need a word. A leading zero stays in the digits field, but it adds nothing to the total. So a user who types a 0 in front gets the same answer as one who does not. Digits typed in Devanagari, the script Hindi uses, count the same as 0 to 9. So your app does not need to convert them first.
Why the country code changes the answer
A country code is made of digits, so our API adds it. The + in front is skipped, but the 1 after it is not. Here is the same New York number with the US country code, in three forms.
What the user typed | Digits added | Total | Number | Fit for John | Fit for Jane |
|---|---|---|---|---|---|
212 555 0147 | 2125550147 | 32 | 5, Mercury | Good fit | Good fit |
+1 212 555 0147 | 12125550147 | 33 | 6, Venus | Good fit | Mixed |
1 212 555 0147 | 12125550147 | 33 | 6, Venus | Good fit | Mixed |
00 1 212 555 0147 | 0012125550147 | 33 | 6, Venus | Good fit | Mixed |
For John, the fit stays good, because 6 is his own number. That is a quirk of this example. Jane Doe's numbers tell a different story. She was born Mar 22, 1992, so her mulank is 4 (Rahu). Her bhagyank is 1 (Sun), from a date total of 28. Without the country code, the phone is a good fit for her. With it, the result is mixed. Her mulank's planet, Rahu, counts Venus as a friend, but her bhagyank's Sun counts Venus as an enemy.
So one phone and one owner can get two answers, and both sums are right. The API cannot tell which one the user meant. Your input field decides. A choice like this is how two calculators can give one person two numbers. Seven others are set out in why numerology calculators disagree.
The guides we read for this post, from Outlook India, Daanyam and AstroMedha, all say to leave the country code out. None of the pages we read says to keep it. If your app follows them, send the number as it is dialed inside its own country.
Letters, extensions and keypad words
Letters and extensions change the total without any error. We ran three more forms for John.
What the user typed | Digits added | Letters set aside | Total | Number | Fit for John |
|---|---|---|---|---|---|
212 555 0147 ext 12 | 212555014712 | e, t, x | 35 | 8, Saturn | Good fit |
212 555 JOHN | 212555 | H, J, N, O | 20 | 2, Moon | Not a good fit |
212 555 5646 | 2125555646 | none | 41 | 5, Mercury | Good fit |
The extension adds a 1 and a 2, so the number moves from 5 to 8. The letters of a keypad word count for nothing. Our API does not turn J into 5 the way a phone keypad does. So 212 555 JOHN keeps only six digits and lands on 2. Typed as keypad digits, 212 555 5646, the same line is back to 5.
The letters are not lost. They come back in ignored_letters, so your app can tell the user what was skipped. When that list is not empty, show it.
Some inputs get no answer at all. A number of only zeros, or one with no digits, returns status 422 with the code invalid_input. The message says the number holds no digit other than zero. An empty value gets a 422 too, and each value can be up to 100 characters. Vehicle plates and house numbers use the same route and digit rule, with their own kind.
How the fit reads the mulank and bhagyank
Our API holds the phone's number up against two of the owner's numbers, the mulank and the bhagyank. For each one, it asks how the owner's planet counts the phone's planet. The answer is the same number, a friend, neutral or an enemy. These links come from the classical friendships between planets. They are one-sided, so the check always runs from the owner to the number.
One stated rule then turns the two links into an outcome, with nothing scored or weighted. At least one friend (or the same number) and no enemy gives good, labelled "Good fit". At least one enemy and no friend gives difficult, labelled "Not a good fit". One of each gives mixed, and neither gives neutral.
You cannot see Rahu (4) or Ketu (7) in the sky. Each marks a spot where the Moon's orbit meets the Sun's path. They have no seat in the classical table, so our API reads Rahu as Saturn and Ketu as Mars. It names the stand-in in a field called via.
We ran one phone number for each digit from 1 to 9. For John, 4, 5, 6 and 8 came back as good fits. The digits 3, 7 and 9 were neutral, and 1 and 2 were not a good fit. Both his numbers are 6, so his two links always agree, and a mixed result cannot happen.
Jane's two numbers differ, so her links often pull apart. Only 3 and 5 came back as good fits for her. The other seven digits were mixed, even 4, her own mulank. Her profile still lists 4, 5, 6 and 8 as friendly numbers, because that list comes from the mulank alone. The phone check reads both numbers. So never use the profile's list in place of a phone check.
Comparing up to 5 numbers without ranking them
To let a user choose between numbers, call POST /v1/numbers. It reads up to 5 numbers of one kind in one call. Each one is read the same way as a single check. We sent five for John.
Order sent | Phone | Total | Number, planet | Fit for John |
|---|---|---|---|---|
1 | 212 555 0147 | 32 | 5, Mercury | Good fit |
2 | 212 555 0199 | 39 | 3, Jupiter | Neutral |
3 | 212 555 0123 | 26 | 8, Saturn | Good fit |
4 | 212 555 0128 | 31 | 4, Rahu (read as Saturn) | Good fit |
5 | 212 555 0170 | 28 | 1, Sun | Not a good fit |
The answer keeps the order you sent and says "ranked": false. Three of the five are good fits, and nothing in the answer breaks that tie. So a "best number" badge would be your app's invention, not the API's.
Show the numbers in the order the user or the shop chose. Print the API's own label beside each one. Do not turn the labels into stars, scores or "lucky" badges. A filter that shows good fits only is fine, since it hides nothing about how each number was judged. A sort that crowns one number is not.
The limit is firm: six numbers in one call get a 422. A single check uses 1 reading credit, and a compare call uses 2. So five numbers take 2 credits in one call, or 5 credits in five calls.
See every field. The number checks page lists what both routes return, with the fit rule and the limits.

What to ask the user to type
Four choices shape the input screen.
Split the country from the number. Put a country picker beside the number field. Send only the number as it is dialed inside that country, such as 212 555 0147 for New York. Tell the user the country code is not counted.
Show what was counted. The answer carries digits, the string of digits the API added. Print it under the result, in a line such as "We added 2125550147". A user who typed an extension or a +1 spots it at once.
Settle letters and extensions first. Give an extension its own field, or cut it off before you send the number. For keypad words, refuse letters, or turn them into keypad digits and say so on screen.
Send the owner's birth date. The fit is about the person who uses the phone. On a family plan, that is the person on each line, not the account holder.
Here is the request, with the docs' sample number.
John Doe, born Aug 15, 1990. The number check takes the owner's birth date only, with no name, time or place.
curl -X POST "https://apiforastrology.com/api/numerology/v1/number" \
-H "Authorization: Bearer $ASTROLOGY_API_KEY" \
-H "Content-Type: application/json" \
-d '{"kind":"mobile","value":"212 555 0147","birth_date":"1990-08-15"}'The answer for John's mobile number, trimmed to the main fields
{
"kind": "mobile",
"value": "212 555 0147",
"digits": "2125550147",
"total": 32,
"compound": 32,
"number": 5,
"ignored_letters": [],
"planet": "Mercury",
"person": { "birth_date": "1990-08-15", "mulank": 6, "bhagyank": 6 },
"fit": {
"links": [
{ "from": "mulank", "from_number": 6, "to_number": 5, "relation": "friend", "via": [] },
{ "from": "bhagyank", "from_number": 6, "to_number": 5, "relation": "friend", "via": [] }
],
"outcome": "good",
"outcome_name": "Good fit"
}
}For a Hindi screen, add lang=hi. Mercury then comes back as बुध in planet_name, and "Good fit" as अच्छा मेल. The codes, such as planet and outcome, stay in English, so your logic does not change.
Every answer also ends with a not_claimed line, which calls numbers leanings, not set outcomes. Put it beside the result. A phone check helps a person choose a number. It does not tell them what will come next. Number checks are one of the six screens in our guide to numerology app development.
Want the short definition? The mobile number numerology entry in our glossary sums up the method, with the vehicle and house checks beside it.

The short version
Mobile number numerology is one sum and one comparison. Add the digits, reduce them to one digit, then read that digit against the owner's mulank and bhagyank. The sum never changes. What the user types does. Our API adds every digit it gets, so your app decides what goes in: no country code, no extension and no bare keypad letters. When several numbers come back, keep them in the order they were sent. Choosing one is the owner's call.



