e-EFKA has no API.So I built a robot that reads it

e-EFKA has no public API for social security contributions. How I built automation that reads it safely, what broke along the way, and how I fixed it.

In this article· 4 sections
  1. What the robot does on each run
  2. What broke (and how I fixed it)
  3. What about myDATA?
  4. I isolate what I don’t control

In Forologika, users see on one screen what they owe to the tax office and to e-EFKA, Greece’s social security fund. For myDATA there is an official API. For e-EFKA contributions and KEAO debts, there isn’t. The only option was automation that logs in to the platform the way the user would.

This is the story of that “robot”: what I built, what broke, and what I learned.

What the robot does on each run

The robot is a headless browser that signs in the way a person would, then reads amounts and due dates from the official notice PDF, not from page text that changes often.

One run of the robot

  1. A headless browser startsPlaywright, on its own server, separate from the website
  2. It signs in through TAXISnetAsking the user for the one-time code (OTP) where needed
  3. It reads the official notice PDFContributions, amounts and due dates
  4. It sends back only what’s neededOnly the data the app needs

What broke (and how I fixed it)

The portal moved

In September 2026 the e-EFKA portal changed address. The old one simply returned “not found”. That’s the biggest risk with this kind of automation: you don’t control the other side. It’s also why the worker is isolated. When something changes, the rest of the app keeps working and users see the last data that was read.

Browsers that never closed

Every sign-in opens a browser. When a session didn’t close properly, its browser stayed open and kept its profile locked, so the next sign-in failed. Now every finished session must close its browser, and new sessions start one at a time.

The 120-second limit

The app waits about two minutes for the worker to reply, and a slow government page could go over that limit. Now the worker always answers within 90 seconds, even if only to say “not finished yet, retrying”, so users are never left staring at a screen that just waits.

Payments that looked unpaid

e-EFKA records payments up to six weeks late, so people who had paid saw their contributions as overdue. For an app that sends alerts, that’s the worst possible mistake.

Now a month only counts as unpaid 60 days after its deadline, once the platform’s delay has been covered.

What about myDATA?

myDATA has an official API, but it also has limits. A business with thousands of documents a quarter quickly hit AADE’s rate limit. The answer was a job queue: each month is read as a separate job, with waiting and retries whenever AADE asks the app to slow down. Users watch the picture fill in gradually, without errors.

I isolate what I don’t control

The automation lives on its own server, so it can’t take the app down when the other side fails. It reads the official PDF, which is more stable than any web page. And it expects government timing: delays in recording payments are the rule, not the exception.


Forologika is live at forologika.net with a 15-day free trial. If your business needs to connect to government or other platforms, the first conversation is free.

Found it useful? Share it

Keep reading

All articles

Have something similar in mind?

Tell me what you need and I’ll suggest the simplest way to get it done.