{"id":"43163166-81c7-4342-b894-d2a6c1709ad9","seo":{},"slug":"epfo-employment-verification-member-service-history","tags":["epfo","employment","india","kyc"],"orgId":"00000000-0000-0000-0000-0000000000a0","title":"EPFO Employment Verification (Member Service History)","domain":"unifiedportal-mem.epfindia.gov.in","status":"ACTIVE","iconUrl":"https://devtool-images.s3.ap-south-1.amazonaws.com/http-provider-brand-logos/epfindia.gov.in-f9540bc2-8b90-4718-a642-946ac7272314.png","visibility":"PUBLIC","description":"EPFO employment verification against the current Member e-SEWA portal (unifiedportal-mem.epfindia.gov.in/memberinterface/). ONE request: memberServiceHistoryNew/loadMemberServiceHistory attests UAN, member name, primary member ID (embeds the EPFO office + establishment code), date of joining, and DATE OF EXIT (EPF) — EPFO renders a literal \"-\" in that cell when no exit has been reported, so a currently-employed member yields dateofexit=\"-\"; treat \"-\" as \"no exit recorded\". Note UAN/Member ID values now carry an EPFO-added \" [P]\"/\"[S]\" suffix (Primary/Secondary), harmless but present in the raw capture. As of v1.5.1 the former second request (exit/employmentJson, latest employer name) has been REMOVED: EPFO's own Mark Exit page (Manage > Mark Exit, /memberinterface/exit/employment) now throws a server-side \"Unexpected error\" on every visit and destroys the session — reproduced live both via the direct rendered link from Service History and via the real Manage menu from the home page. This is a break on EPFO's backend, not the recipe; re-add employer name here once EPFO fixes that page. In the meantime, employer name is available from the sibling provider \"epfo-employment-history\" (da22a39c-0dc9-40d3-a98f-18cf1150229b), which sources it from the separate Member Passbook portal (passbook.epfindia.gov.in) instead of this one. EPFO binds sessions to their originating client and HDIV state tokens are single-use, so out-of-band replay returns 302/500 — no selector here can be validated by replay_request or run_proof. HDIV rejects a hand-built _HDIV_STATE_ URL and destroys the session, so the injection navigates only by clicking rendered links, after the page has fully loaded. disableRequestReplay must be TRUE; the publish API cannot always guarantee this survives in the dashboard — verify the checkbox (\"Enable Document Request Replay\" UNCHECKED) after each new version.","effectiveSeo":{"title":"EPFO Employment Verification (Member Service History) — verify uan","brandUrl":"https://unifiedportal-mem.epfindia.gov.in","brandName":"EPFO Employment Verification (Member Service History)","dataPoints":["uan","memberid","dateofjoining","membername","dateofexit"],"description":"EPFO employment verification against the current Member e-SEWA portal (unifiedportal-mem.epfindia.gov.in/memberinterface/). ONE request: memberServiceHistoryNew/loadMemberServiceHistory attests UAN, member name, primary member ID (embeds the EPFO office + establishment code), date of joining, and DATE OF EXIT (EPF) — EPFO renders a literal \"-\" in that cell when no exit has been reported, so a currently-employed member yields dateofexit=\"-\"; treat \"-\" as \"no exit recorded\". Note UAN/Member ID values now carry an EPFO-added \" [P]\"/\"[S]\" suffix (Primary/Secondary), harmless but present in the raw capture. As of v1.5.1 the former second request (exit/employmentJson, latest employer name) has been REMOVED: EPFO's own Mark Exit page (Manage > Mark Exit, /memberinterface/exit/employment) now throws a server-side \"Unexpected error\" on every visit and destroys the session — reproduced live both via the direct rendered link from Service History and via the real Manage menu from the home page. This is a break on EPFO's backend, not the recipe; re-add employer name here once EPFO fixes that page. In the meantime, employer name is available from the sibling provider \"epfo-employment-history\" (da22a39c-0dc9-40d3-a98f-18cf1150229b), which sources it from the separate Member Passbook portal (passbook.epfindia.gov.in) instead of this one. EPFO binds sessions to their originating client and HDIV state tokens are single-use, so out-of-band replay returns 302/500 — no selector here can be validated by replay_request or run_proof. HDIV rejects a hand-built _HDIV_STATE_ URL and destroys the session, so the injection navigates only by clicking rendered links, after the page has fully loaded. disableRequestReplay must be TRUE; the publish API cannot always guarantee this survives in the dashboard — verify the checkbox (\"Enable Document Request Replay\" UNCHECKED) after each new version.","primaryDataPoint":"uan"},"latestVersion":{"major":1,"minor":5,"patch":1},"createMetadata":{"doneAt":"2026-10-20T06:15:49.752772+00:00"},"seoSuggestions":{"title":"Unifiedportal-Mem","iconUrl":"https://www.google.com/s2/favicons?domain=unifiedportal-mem.epfindia.gov.in&sz=128","brandUrl":"https://unifiedportal-mem.epfindia.gov.in","dataPoints":["uan","memberid","dateofjoining","membername","dateofexit"],"primaryDataPoint":"uan"},"updateMetadata":{"doneAt":"2026-10-23T11:36:20.126939+00:00"}}