Does Shelby Systems publish a public API?
Not in any usable third-party sense. What exists is an administrator setup guide: support has to enable access for your instance, and the credential is generated inside that instance. There is no open developer portal to register with and no published interface a software vendor can build a shipping product against. A partners URL that once circulated is no longer live and is absent from the site's sitemap, so it is not evidence of anything either way.
Why does instance-gated access change the answer?
An interface that exists only after your vendor's support team switches it on for your organisation is not something another company can promise you in advance. Every deployment becomes its own project, gated on a support request you have to make and a configuration somebody has to complete. Commercially that behaves much more like file integration than like a documented API, and it should be described that way rather than dressed up in a marketplace listing.
What does that mean for card and expense automation?
Card activity reaches Shelby the way most fund accounting systems take outside data: keyed against the fund and account, or imported as a file in a layout the system accepts. For a church or nonprofit finance office the hand-keying version means chasing receipts from ministry leads and program staff, decoding a statement line by line, and coding restricted spend after the fact — which is the worst possible moment to discover that a restricted fund paid for something it should not have.
How does Vergo work with Shelby Systems?
Vergo captures coding and documentation at the point of spend. The cardholder picks the fund and account in Vergo when the charge posts and photographs the receipt. Approvals run in Vergo, so a ministry lead or the finance director signs off before anything moves. Vergo then produces a custom-built CSV export matched to the import format Shelby expects, and the finance office loads one coded batch instead of rekeying a month of card activity.
Vergo does not claim an API sync with Shelby Systems, because Shelby does not publish one openly. The file path is the honest one, and with coding, receipts, and approvals already attached it leaves the finance office less work than a sync that does not exist.
What does a nonprofit actually need from this?
Not a live connection — visibility before the money is gone and documentation good enough to survive a review. Both are captured at the point of spend rather than at the point of posting: the fund, the program, the reason, the receipt, and the approval. A finance office that has those five things on every card charge is in better shape than one waiting on an interface that may or may not be enabled on its instance next year.
What should a finance office ask?
Ask Shelby support what access is available on your instance and what enabling it involves. Ask any vendor claiming a Shelby integration whether it works on every customer's instance or only after a support request and a configuration project. The answers are usually different, and the difference is your implementation timeline and your budget.
Does Shelby Systems have a public API?
No open developer documentation is published. The available material is an administrator setup guide requiring support to enable access and a secret generated inside your own instance.
Does the Shelby partners page prove an integration?
No. The partner URL that once circulated is dead and absent from the sitemap, and a partner listing would not give third-party software a documented interface in any case.
How does Vergo get card transactions into Shelby?
Cardholders code charges to funds and accounts in Vergo with receipts attached, approvals run in Vergo, and Vergo generates a custom CSV export matched to Shelby's import format for the finance office to load.
Does this work for restricted funds?
Yes. Fund coding is captured at the point of spend and reviewed at approval, so restricted spending is identified before the batch is imported rather than after the fact.
