Skip to content
For temples, trusts & organisations

Today's Seva Kartas, on the wall

A display for the screen in your hall, or a panel in your own portal. It names the people whose seva is being performed today — both those who booked it and those whose Mūla Nidhi endowment brings it round on this day every year.

Both kinds of seva karta

🪔

Permanent — Mūla Nidhi

A corpus donor endows a seva once. It recurs on the same day every year, for as long as the institution stands. The wall carries them first: they endowed the day.

📅

One-time booking

A seva booked for today — a Śrāddha, an Abhiṣeka, a Saṃskāra. It appears on the wall on the day it is performed, and then makes way.

Live example

Full-screen wall mode →

Rendered by the same module a portal would embed, against today's real pañcāṅga. The names and places are invented for the demonstration; the deity images are the platform's own. A real wall reads from the institution's own bookings.

Whose face appears, and whose does not

A seva karta chooses. The choice is recorded against the seva, not the person, so the same devotee may appear for one offering and not another.

  1. Opted in, photograph held — their photograph is shown. No card below uses one: putting a stranger's face on a public page to demonstrate a feature is not a thing to do casually, and the case that governs most cards on a real wall is the next one anyway.
  2. Not opted in, or no photograph — the deity image for that seva is shown in its place. Your images, configured per seva category.
  3. No deity image configured — a drawn emblem, a lamp within a lotus. Never a letter in a circle: nobody is missing from this wall, and the image should not look like a gap where a person ought to be.

A withheld name is treated the same way — the card reads Nāma gupta — offered without name, and a line at the foot says how many sevas were offered that way, so the count is honest without the names being.

The server withholds; the display does not. A donor who has not opted in must have null sent for that field, not a value the page is trusted to hide. No endpoint feeding this wall should carry a phone number, an email address, a postal address or an amount — the contract has no place to put them.

Put it on your own screen

One element and one script, the same as the pañcāṅga line. Your portal renders the seva list server-side into data-payload — it already holds the bookings and already knows who has opted in: 

<div data-swadharma-seva-wall
     data-title="Today's Seva Kartas"
     data-layout="wall"
     data-rotate="9"
     data-payload='{"date":"2026-08-24","tithi":"Śrāvaṇa Śukla Dvādaśī",
       "locality":"Mysore","sevas":[
         {"id":"1","kind":"corpus","sevaName":"Nitya Abhiṣeka","sevaCode":"ABHISHEKA",
          "name":"…","place":"Rajahmundry, Andhra Pradesh","photo":null,
          "deityImage":"/images/abhisheka.jpg","since":2014}]}'></div>
<script src="https://swadharmaservices.in/seva-wall.js" async></script>

Prefer to fetch? Use data-endpoint="/your/route" instead and the wall will request it, adding ?date= for the installation's today. The response takes the same shape.

data-layout="grid" shows every seva karta at once — better for a page panel; "wall" rotates one large card at a time, for a screen in the hall. data-deities takes JSON mapping a seva code to an image URL. data-theme="dark" suits a dark hall display. The wall refreshes itself every five minutes, and turns over at your installation's midnight rather than the viewer's.

Where the data comes from

Each installation renders its own seva list server-side and passes it to the wall. There is no shared public endpoint, and that is the decision (VKG, 2026-08-24): a portal already holds its own bookings and already knows which of its donors have opted in, so the privacy projection stays inside the institution that owes it rather than being centralised on a platform route. Put the payload in data-payload and the wall renders it with no second request.

A portal that would rather fetch than inline can point data-endpoint at its own route instead. Either way the shape is the same, and it is documented at the top of seva-wall.js — the important line being that the server sends null for anything a donor has not consented to publish, so nothing on this side is trusted to hide it.