2
6 Comments

Opening an API for (remote) UN jobs

During the past weeks, I discussed with some of you about what to do with the data I collected about jobs in the UN (remote and not remote).

Two IHackers asked about API access, so here is a draft, only including remote jobs at the moment:
https://untalent.org/api/v1/homebased?page=1

You can use these data as you want, as long as you send people to https://untalent.org/jobs/{jobSlug} at some point. That's why I give access, after all 😅

Please DM me (https://twitter.com/NathanaelKhodl) in case you start something, as I will introduce API keys soon.

Disclaimer as usual: even if I'm doing my best, I'm not responsible for the data or what you do with it, etc...

Let me know what else you need!

posted to Icon for group Remote jobs
Remote jobs
on August 18, 2020
  1. 1

    Hello Khdol

    I tried importing from your API.

    I have a couple of questions/suggestions

    Homebased jobs also appear in the generic listing of all jobs, right?
    It would be very useful if you could add a field to specify if it is a homebased/remote category or something else. It's to avoid having to import from both endpoints, and to avoid duplicates.

    It would also be useful if the date of publication of the ad appeared.
    Now only the expiration date appears.

    1. 1

      Yes, you're right!

      I added a is_homebased field. If missing, then it's not home-based.
      If you want to import everything, you can now use the /jobs endpoint only.

      I do not have the initial publication date.

  2. 1

    Follow-up: you can now get all the jobs on the /jobs endpoint: https://untalent.org/api/v1/jobs?page=1

  3. 1

    Good job.

    What I don't see is the body text.
    For example, in Vabiso.com I need it so that users can search the text from the form.

    And as a recommendation, I would like the API to return the url for each job offer.
    In my case, it doesn't cost me anything to add the domain name of the website in front of the {slug}. But thinking about it being the easiest thing to use for anyone ... I particularly like the idea that a frontend can read a json without processing the data.

    1. 1

      I added a short description, but to be honest, the full version is not efficient for keyword search, as the context is too important in that case: they talk a lot about the people you'll collaborate with and other information not related with the position itself.

      But no worries, I'll add a keywords field soon, where I will extract keywords depending on the area of work.

      There is now an url field instead of slug.

      And I will add non-remote searches.

      1. 1

        Okay, perfect.

        If all goes well, I'll try to import remote jobs (from your API and other sites) this weekend or next.

        If I have any problems I'll let you know.

Trending on Indie Hackers
I've been building for months and made $0. Here's the honest psychological reason — and it's not what I expected. User Avatar 177 comments 7 years in agency, 200+ B2B campaigns, now building Outbound Glow User Avatar 59 comments This system tells you what’s working in your startup — every week User Avatar 53 comments 11 Weeks Ago I Had 0 Users. Now VIDI Has Reviewed $10M+ in Contracts - and I’m Opening a Small SAFE Round User Avatar 46 comments The "Book a Demo" Button Was Killing My Pipeline. Here's What I Replaced It With. User Avatar 29 comments My AI bill was bleeding me dry, so I built a "Smart Meter" for LLMs User Avatar 18 comments