How to Migrate from Prokerala to Vedika API: A Practical Guide

Why Developers Consider Migrating

Prokerala is a solid astrology API with a real track record. Their astronomical calculations are reliable, their docs are clear, and they have been serving developers since roughly 2018. If your current Prokerala integration works and your requirements have not changed, there may be no reason to switch.

That said, developers do outgrow a provider. Here are the concrete reasons we hear from teams that migrate:

1. Rate limits and scaling headroom. Prokerala's Emerald plan caps at 120 requests/minute. For a consumer app with a few thousand daily active users, that is tight. If traffic spikes during festivals (Diwali, Pongal, Navratri) or viral moments, you hit the ceiling. Vedika rate limits range from 60/min on Starter to 500/min on Enterprise, with burst allowances. At the Pro tier (120/min) you match Prokerala's Emerald ceiling at a lower monthly cost.

2. No AI chatbot endpoint. This is Vedika's genuine differentiator. If you are building an app where users ask natural-language astrology questions ("When should I start my business this month?" or "Explain my Rahu Mahadasha"), Prokerala has no equivalent. You would need to layer your own LLM on top of Prokerala's raw calculations. Vedika AI handles the full pipeline: birth chart computation, Vedic interpretation, and natural language response in 30+ languages via a single POST request.

3. OAuth2 token management adds friction. Prokerala uses the OAuth2 client_credentials flow. You fetch a token, store it, refresh it before expiry, handle 401 retries. It is a well-understood pattern, but it is still code you have to write, test, and maintain. Vedika uses a static API key in the x-api-key header. No token lifecycle, no refresh logic.

4. Scope gaps. Prokerala focuses primarily on South Indian Vedic astrology. If your product needs North Indian diamond chart rendering, KP (Krishnamurti Paddhati) calculations, Western tropical charts, numerology, or Muhurta, you end up stitching together multiple providers. Vedika covers 120+ endpoints across Vedic, Western, and numerology from one API.

5. Cost at scale. Prokerala's Emerald plan runs approximately $30/month for 10,000 requests. Vedika's Starter is $12/month for 5,000 requests, and Pro is $60/month for 25,000. Per-request cost favors Vedika at higher volumes, though at very low volumes Prokerala may be cheaper depending on which plan you land on. We break down the numbers in detail later.

What Prokerala Does Better (Be Honest)

A migration guide that only lists reasons to switch is not trustworthy. Here is where Prokerala has the edge:

If Prokerala covers your requirements and you are not hitting its limits, migrating just because a new option exists is wasted engineering time. Migrate when you have a concrete reason.

Endpoint Mapping: Prokerala to Vedika

The table below maps Prokerala's most-used endpoints to their Vedika equivalents. The request/response shapes differ (covered in the next sections), but the functionality maps cleanly.

For the complete endpoint list, see the Vedika API documentation. The sandbox at vedika.io/sandbox lets you test all 65 mock endpoints without authentication.

Authentication Migration: OAuth2 to API Key

This is typically the first thing you change, and it simplifies your code. Here is the before and after:

Before: Prokerala OAuth2 Flow

// Prokerala requires OAuth2 client_credentials
const CLIENT_ID = process.env.PROKERALA_CLIENT_ID;
const CLIENT_SECRET = process.env.PROKERALA_CLIENT_SECRET;

let accessToken = null;
let tokenExpiry = 0;

async function getProkeralaToken() {
    if (accessToken && Date.now() < tokenExpiry) {
        return accessToken;
    }

    const response = await fetch('https://api.prokerala.com/token', {
        method: 'POST',
        headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
        body: `grant_type=client_credentials&client_id=${CLIENT_ID}&client_secret=${CLIENT_SECRET}`
    });

    const data = await response.json();
    accessToken = data.access_token;
    // Refresh 60 seconds before actual expiry
    tokenExpiry = Date.now() + (data.expires_in - 60) * 1000;
    return accessToken;
}

async function callProkerala(endpoint, params) {
    const token = await getProkeralaToken();
    const response = await fetch(`https://api.prokerala.com${endpoint}`, {
        method: 'POST',
        headers: {
            'Content-Type': 'application/json',
            'Authorization': `Bearer ${token}`
        },
        body: JSON.stringify(params)
    });

    if (response.status === 401) {
        // Token expired, force refresh and retry
        accessToken = null;
        const newToken = await getProkeralaToken();
        return fetch(`https://api.prokerala.com${endpoint}`, {
            method: 'POST',
            headers: {
                'Content-Type': 'application/json',
                'Authorization': `Bearer ${newToken}`
            },
            body: JSON.stringify(params)
        }).then(r => r.json());
    }

    return response.json();
}

After: Vedika API Key

// Vedika uses a static API key in the header
const VEDIKA_API_KEY = process.env.VEDIKA_API_KEY; // vk_live_...

async function callVedika(endpoint, params) {
    const response = await fetch(`https://api.vedika.io${endpoint}`, {
        method: 'POST',
        headers: {
            'Content-Type': 'application/json',
            'x-api-key': VEDIKA_API_KEY
        },
        body: JSON.stringify(params)
    });

    return response.json();
}

That is the entire auth migration. No token lifecycle, no expiry tracking, no retry-on-401. Your API key is sent with every request. If it is invalid or your subscription has lapsed, you get a 401 or 403 with a clear error message. Rotate keys from the Vedika console.

Request and Response Format Differences

Both APIs accept JSON POST bodies, but field names and response structures differ. Here are the three most common endpoints compared side by side.

Birth Chart / Kundli

// PROKERALA REQUEST
POST /v2/astrology/kundli
{
    "datetime": "2000-06-15T10:30:00+05:30",
    "coordinates": {
        "latitude": 18.5204,
        "longitude": 73.8567
    },
    "ayanamsa": 1  // Numeric code: 1 = Lahiri
}

// PROKERALA RESPONSE (simplified)
{
    "data": {
        "nakshatra_details": {
            "nakshatra": { "name": "Rohini", "lord": "Moon" },
            "chandra_rasi": { "name": "Taurus" }
        },
        "planet_positions": [
            {
                "id": 0,
                "name": "Sun",
                "sign": { "id": 1, "name": "Taurus" },
                "degree": 0.8456,
                "is_retrograde": false,
                "nakshatra": { "name": "Mrigashirsha", "lord": "Mars" }
            }
        ],
        "house_cusps": [ /* 12 entries */ ]
    }
}

// ================================================

// VEDIKA REQUEST
POST /v2/astrology/birth-chart
{
    "datetime": "2000-06-15T10:30:00+05:30",
    "latitude": 18.5204,
    "longitude": 73.8567,
    "ayanamsa": "lahiri"  // String name, not numeric code
}

// VEDIKA RESPONSE (simplified)
{
    "birthChart": {
        "ascendant": {
            "sign": "Leo",
            "degree": 15.342,
            "nakshatra": "Purva Phalguni",
            "nakshatraPada": 2
        },
        "planets": [
            {
                "name": "Sun",
                "sign": "Taurus",
                "degree": 0.846,
                "house": 10,
                "nakshatra": "Mrigashirsha",
                "nakshatraPada": 3,
                "nakshatraLord": "Mars",
                "isRetrograde": false,
                "dignity": "neutral"
            }
        ],
        "houses": [ /* 12 entries with sign and degree */ ]
    },
    "meta": {
        "ayanamsa": "lahiri",
        "ayanamsaValue": 23.8563,
        "calculationEngine": "Swiss Ephemeris"
    }
}

Key differences to note:

• Prokerala nests coordinates inside a coordinates object; Vedika takes latitude and longitude as flat fields
• Prokerala uses numeric ayanamsa codes (1 = Lahiri, 3 = Raman); Vedika uses string names ("lahiri", "raman")
• Prokerala uses snake_case throughout; Vedika uses camelCase
• Vedika includes dignity (exalted, debilitated, own sign, neutral) and house number per planet; Prokerala returns these separately
• Vedika includes nakshatra lord inline with the planet; Prokerala puts it in a nested nakshatra object

Panchang

// PROKERALA REQUEST
POST /v2/astrology/panchang
{
    "datetime": "2026-02-10T06:00:00+05:30",
    "coordinates": {
        "latitude": 28.6139,
        "longitude": 77.2090
    },
    "ayanamsa": 1
}

// PROKERALA RESPONSE (simplified)
{
    "data": {
        "vaara": { "name": "Tuesday" },
        "nakshatra": [
            { "name": "Ashwini", "end": "2026-02-10T14:23:00+05:30" }
        ],
        "tithi": [
            { "name": "Trayodashi", "paksha": "Krishna", "end": "..." }
        ],
        "yoga": [
            { "name": "Siddhi", "end": "..." }
        ],
        "karana": [
            { "name": "Vanija", "end": "..." }
        ],
        "sunrise": "2026-02-10T06:58:00+05:30",
        "sunset": "2026-02-10T18:05:00+05:30"
    }
}

// ================================================

// VEDIKA REQUEST
POST /v2/astrology/panchang
{
    "datetime": "2026-02-10T06:00:00+05:30",
    "latitude": 28.6139,
    "longitude": 77.2090,
    "ayanamsa": "lahiri"
}

// VEDIKA RESPONSE (simplified)
{
    "panchang": {
        "vaara": "Tuesday",
        "nakshatra": {
            "name": "Ashwini",
            "lord": "Ketu",
            "endTime": "2026-02-10T14:23:00+05:30"
        },
        "tithi": {
            "name": "Trayodashi",
            "paksha": "Krishna",
            "endTime": "2026-02-10T..."
        },
        "yoga": {
            "name": "Siddhi",
            "endTime": "2026-02-10T..."
        },
        "karana": {
            "name": "Vanija",
            "endTime": "2026-02-10T..."
        },
        "sunrise": "2026-02-10T06:58:00+05:30",
        "sunset": "2026-02-10T18:05:00+05:30",
        "moonrise": "2026-02-10T...",
        "moonset": "2026-02-10T..."
    }
}

Both use Swiss Ephemeris under the hood, so the computed values (sunrise, tithi boundaries, nakshatra transitions) should agree closely. Differences beyond a few seconds usually indicate different ayanamsa settings or slightly different geographic coordinates.

Planet Positions

// PROKERALA REQUEST
POST /v2/astrology/planet-position
{
    "datetime": "2026-02-10T12:00:00+05:30",
    "coordinates": { "latitude": 19.076, "longitude": 72.8777 },
    "ayanamsa": 1
}

// PROKERALA RESPONSE (one planet shown)
{
    "data": {
        "planet_positions": [
            {
                "id": 0,
                "name": "Sun",
                "sign": { "id": 10, "name": "Aquarius" },
                "sign_degree": 27.5432,
                "is_retrograde": false,
                "nakshatra": {
                    "name": "Purva Bhadrapada",
                    "lord": { "name": "Jupiter" },
                    "pada": 3
                }
            }
        ]
    }
}

// ================================================

// VEDIKA REQUEST
POST /v2/astrology/planets
{
    "datetime": "2026-02-10T12:00:00+05:30",
    "latitude": 19.076,
    "longitude": 72.8777,
    "ayanamsa": "lahiri"
}

// VEDIKA RESPONSE (one planet shown)
{
    "planets": [
        {
            "name": "Sun",
            "sign": "Aquarius",
            "longitude": 327.543,
            "signDegree": 27.543,
            "nakshatra": "Purva Bhadrapada",
            "nakshatraPada": 3,
            "nakshatraLord": "Jupiter",
            "isRetrograde": false,
            "house": 7,
            "dignity": "neutral",
            "speed": 1.012
        }
    ],
    "meta": {
        "ayanamsa": "lahiri",
        "ayanamsaValue": 24.218
    }
}

The structural difference: Prokerala nests nakshatra details in sub-objects with their own lord objects. Vedika flattens everything onto the planet object. This matters when you write your adapter (next section).

Building a Migration Adapter

The safest migration strategy: keep your existing code unchanged and swap the data source behind an adapter. Your app calls the adapter with the same shape it always used, the adapter calls Vedika and transforms the response to match Prokerala's format. Once everything works, you can refactor at your own pace.

/**
 * Migration adapter: wraps Vedika API to return
 * Prokerala-compatible response shapes.
 *
 * Usage: Replace your Prokerala base URL with this adapter.
 * Your existing parsing code keeps working.
 */
class ProkeralaToVedikaAdapter {
    constructor(vedikaApiKey) {
        this.apiKey = vedikaApiKey;
        this.baseUrl = 'https://api.vedika.io';
    }

    async _callVedika(endpoint, params) {
        const response = await fetch(`${this.baseUrl}${endpoint}`, {
            method: 'POST',
            headers: {
                'Content-Type': 'application/json',
                'x-api-key': this.apiKey
            },
            body: JSON.stringify(params)
        });
        if (!response.ok) {
            const err = await response.json().catch(() => ({}));
            throw new Error(`Vedika API error ${response.status}: ${err.error || 'Unknown'}`);
        }
        return response.json();
    }

    // Transform Vedika flat params to extract nested coordinates
    _normalizeParams(prokeralaParams) {
        const { coordinates, ayanamsa, ...rest } = prokeralaParams;
        return {
            ...rest,
            latitude: coordinates?.latitude ?? rest.latitude,
            longitude: coordinates?.longitude ?? rest.longitude,
            // Map numeric ayanamsa codes to Vedika string names
            ayanamsa: this._mapAyanamsa(ayanamsa)
        };
    }

    _mapAyanamsa(code) {
        const map = { 1: 'lahiri', 3: 'raman', 5: 'krishnamurti', 7: 'fagan_bradley' };
        if (typeof code === 'string') return code;
        return map[code] || 'lahiri';
    }

    // Birth chart: /v2/astrology/kundli -> /v2/astrology/birth-chart
    async getKundli(params) {
        const normalized = this._normalizeParams(params);
        const vedika = await this._callVedika('/v2/astrology/birth-chart', normalized);
        const chart = vedika.birthChart || {};

        return {
            data: {
                planet_positions: (chart.planets || []).map(p => ({
                    name: p.name,
                    sign: { name: p.sign },
                    degree: p.signDegree,
                    sign_degree: p.signDegree,
                    is_retrograde: p.isRetrograde,
                    nakshatra: {
                        name: p.nakshatra,
                        lord: { name: p.nakshatraLord },
                        pada: p.nakshatraPada
                    }
                })),
                house_cusps: (chart.houses || []).map(h => ({
                    sign: { name: h.sign },
                    degree: h.degree
                })),
                nakshatra_details: chart.ascendant ? {
                    nakshatra: { name: chart.ascendant.nakshatra },
                    chandra_rasi: {
                        name: (chart.planets || []).find(p =>
                            p.name === 'Moon')?.sign || ''
                    }
                } : null
            }
        };
    }

    // Planet positions: /v2/astrology/planet-position -> /v2/astrology/planets
    async getPlanetPositions(params) {
        const normalized = this._normalizeParams(params);
        const vedika = await this._callVedika('/v2/astrology/planets', normalized);

        return {
            data: {
                planet_positions: (vedika.planets || []).map(p => ({
                    name: p.name,
                    sign: { name: p.sign },
                    sign_degree: p.signDegree,
                    is_retrograde: p.isRetrograde,
                    nakshatra: {
                        name: p.nakshatra,
                        lord: { name: p.nakshatraLord },
                        pada: p.nakshatraPada
                    }
                }))
            }
        };
    }

    // Panchang: same path, different shapes
    async getPanchang(params) {
        const normalized = this._normalizeParams(params);
        const vedika = await this._callVedika('/v2/astrology/panchang', normalized);
        const p = vedika.panchang || {};

        return {
            data: {
                vaara: { name: p.vaara },
                nakshatra: [{ name: p.nakshatra?.name, end: p.nakshatra?.endTime }],
                tithi: [{ name: p.tithi?.name, paksha: p.tithi?.paksha, end: p.tithi?.endTime }],
                yoga: [{ name: p.yoga?.name, end: p.yoga?.endTime }],
                karana: [{ name: p.karana?.name, end: p.karana?.endTime }],
                sunrise: p.sunrise,
                sunset: p.sunset
            }
        };
    }
}

// Usage: drop-in replacement
const adapter = new ProkeralaToVedikaAdapter('vk_live_your_key_here');

// Your existing code keeps working:
const kundli = await adapter.getKundli({
    datetime: '2000-06-15T10:30:00+05:30',
    coordinates: { latitude: 18.5204, longitude: 73.8567 },
    ayanamsa: 1
});

// kundli.data.planet_positions[0].sign.name  -> works as before
// kundli.data.planet_positions[0].nakshatra.lord.name -> works as before

This adapter handles the three most common endpoints. Extend it for dosha, matching, and dasha endpoints following the same pattern: call Vedika, reshape the response to match Prokerala's structure.

The adapter approach lets you migrate one endpoint at a time. Run both providers in parallel for a week, compare outputs, then cut over when you are confident.

Gotchas During Migration

These are the issues we have seen developers hit during real migrations. Save yourself the debugging time.

1. Ayanamsa Default May Differ

Prokerala defaults to Lahiri (code 1) if you do not specify ayanamsa. Vedika also defaults to Lahiri, but the exact ayanamsa value at a given date can differ by a few arcseconds between implementations. This is enough to shift a planet near a sign boundary. Always set ayanamsa explicitly in both systems and verify that your critical test cases produce the same sign placements.

2. snake_case vs camelCase

Prokerala returns is_retrograde, sign_degree, planet_positions. Vedika returns isRetrograde, signDegree, planets. If you are using TypeScript interfaces or JSON parsing with strict field names, every field name needs updating. The adapter above handles this, but if you migrate directly, do a find-and-replace audit.

3. Nakshatra Lord Location

Prokerala returns nakshatra lord inside a nested nakshatra.lord object on each planet. Vedika includes it as a flat nakshatraLord string field on the planet object. If your code does planet.nakshatra.lord.name, it will break on Vedika's response. Change it to planet.nakshatraLord or use the adapter.

4. Timezone Format

Both APIs accept ISO 8601 datetime strings with timezone offsets (+05:30, -08:00). However, Vedika's V1 endpoints require UTC offset format, not IANA timezone names. If your app stores timezones as Asia/Kolkata, convert to +05:30 before calling the API. The V2 endpoints accept both formats.

5. Flush Your Caches

If your app caches API responses (and it should), flush the cache during migration. Prokerala and Vedika responses have different shapes. A cached Prokerala response parsed by code expecting Vedika's format will throw, and the error will be confusing because it looks like the API returned bad data.

6. Rate Limit Headers Differ

Prokerala returns X-RateLimit-Limit and X-RateLimit-Remaining. Vedika returns rate limit information in the response body when you hit the limit (429 status code) and in X-RateLimit-* headers. If your retry logic parses specific header names, update it.

7. Error Response Format

Prokerala returns errors in { "errors": [...] } format. Vedika returns { "error": "message", "code": "ERROR_CODE" }. Update your error handling to parse the correct shape. Both return standard HTTP status codes (400, 401, 403, 429, 500).

Cost Comparison

Honest numbers. Prokerala pricing is from their published plans as of early 2026. Vedika pricing is from our current published rates.

Where Prokerala wins on cost: If you need fewer than 1,500 requests/month, Prokerala's free tier (50/day) covers you at $0. Vedika has no free production tier. For very low-volume projects, Prokerala is the cheaper choice.

Where Vedika wins on cost: At 10,000+ requests/month, Vedika Pro ($60/mo for 25K requests) gives you 2.5x the volume at 2x the price of Prokerala Emerald. Per-request cost drops further on Business ($120/mo for 50K) and Enterprise ($240/mo for 100K+) tiers.

The hidden cost: If you need AI chatbot functionality and Prokerala does not offer it, you would layer an LLM service on top. LLM API calls at scale can cost $0.01-$0.10 per query depending on the model and provider. Vedika AI bundles the LLM cost into the per-request price.

Step-by-Step Migration Checklist

A practical migration plan for a production app. Adjust timelines based on your team size and test coverage.

When You Should NOT Migrate

We would rather lose a potential customer than have you waste engineering time on a migration that does not help you. Do not migrate if:

• Your app only needs basic Kundli and Panchang data, and Prokerala handles it fine
• You are not hitting rate limits and do not need the AI chatbot
• Your team is small and the migration would take resources away from feature development
• You rely on Prokerala's free tier and your volume stays under 50 requests/day
• You have complex OAuth2 infrastructure that your other services also use, and the API key model does not fit your architecture

A good API provider is one that serves your needs. If that is Prokerala today, it is Prokerala today. This guide will be here when your needs change.

Hybrid Approach: Use Both Providers

Some teams do not fully migrate. They use Prokerala for raw calculations and Vedika for the AI chatbot and Western astrology endpoints. This is a legitimate architecture:

// Hybrid: Prokerala for calculations, Vedika for AI
async function getAstrologyData(birthDetails, userQuestion) {
    // Raw calculations from your existing Prokerala integration
    const birthChart = await prokerala.getKundli(birthDetails);
    const planets = await prokerala.getPlanetPositions(birthDetails);

    // AI interpretation from Vedika (no Prokerala equivalent)
    const aiResponse = await fetch('https://api.vedika.io/v1/chat', {
        method: 'POST',
        headers: {
            'Content-Type': 'application/json',
            'x-api-key': VEDIKA_API_KEY
        },
        body: JSON.stringify({
            question: userQuestion,
            birthDetails: {
                datetime: birthDetails.datetime,
                latitude: birthDetails.coordinates.latitude,
                longitude: birthDetails.coordinates.longitude,
                timezone: '+05:30'
            }
        })
    });

    return {
        chart: birthChart,        // from Prokerala
        planets: planets,          // from Prokerala
        interpretation: await aiResponse.json()  // from Vedika
    };
}

This gives you the best of both: Prokerala's established calculation pipeline (no migration risk) plus Vedika AI's natural language interpretation (no LLM integration work). You pay for two APIs, but you avoid migration effort entirely.