cal.com
cal.com copied to clipboard
calcom
[CAL-3414] App: Lever.co
if anyone wants to pick this up, here's how to make an app: https://docs.cal.com/how-to-guides/how-to-build-an-app
💎 $200 bounty created by cal
👉 No need to comment asking to work on it. Just open a PR and claim the bounty with /claim #3717 inside the PR
📝 Before proceeding, please make sure you can receive payouts in your country
💵 Payment arrives in your account 2-5 days after the bounty is rewarded
💯 You keep 100% of the bounty award
🙏 Thank you for contributing to calcom/cal.com!
👉 Add a bounty • Share on socials
![algora-pbc[bot] avatar](https://avatars.githubusercontent.com/in/275896?v=4 "Published by a pub.dev verified publisher"){kind=small}
💎 $200.00 bounty created by PeerRich after accepting @PeerRich's bid
👉 To claim this bounty, submit a pull request that includes the text /claim #3717 somewhere in its body
📝 To receive payouts, complete Stripe Connect on your Algora dashboard
💵 Payment arrives in your account 2-5 days after the bounty is rewarded
💯 You keep 100% of the bounty award
🌳 If you want, you can donate 100% of the rewards to climate change projects!
🙏 Thank you for contributing to calcom/cal.com!
@PeerRich Can you provide what features are required for this app? I would like to pick this up.
if connected, the incoming bookings should go to lever.co into the application column
i think we should use https://merge.dev
https://docs.merge.dev/ats/applications/
I've been looking into this one today, building a Merge app to fulfil this PR as well #1549
Merge supports both CRMs and ATS', but I'm just exploring their ATS side of things for now – given the scope of these issues.
It looks like we'll be able to log Candidates (bookees) and Activities (the booking) through their APIs, which will then feed into whatever upstream ATS customers are using.
I'm also using Workable as the upstream ATS provider for now. Merge.dev suggests them during onboarding as they have developer accounts available, whereas Lever.co do not. I assume that's okay, given we're handing off the responsibility of ATS integration specifics to Merge?
Going to park this for now. I don't think Merge makes this as simple as I thought it was going to be.
When integrating with Merge, our users have to choose what "Linked account" they're using for the integration – the linked account pointing to which of various upstream providers the user's wanting to keep in sync.
Each provider has their own varying set of supported and required fields when creating records. For example, with some providers we have to create an Application before we can create a Candidate record, whereas in others we must create the Candidate and then the Application. And some systems can support multiple applications for the same candidate, so there's possibly the need to resolve which existing applications might be appropriate to use rather than creating a new one.
Long story short, I feel like it's getting complicated. Not impossible, but not quite as simple as I interpreted "unified API". I don't think I'm going to have the time to fully explore this rabbit hole.
May be value in bringing the idea back to just a few provider-specific integrations. We'll lose the breadth of support Merge would give, but it should be simpler code, and potentially less of a blocker to customers (If they have Cal.com and Lever, having to procure & pay for Merge could be an issue?)
@PeerRich Can you point out any examples from our codebase so that it will be easier for me to integrate.
Going to park this for now. I don't think Merge makes this as simple as I thought it was going to be.
When integrating with Merge, our users have to choose what "Linked account" they're using for the integration – the linked account pointing to which of various upstream providers the user's wanting to keep in sync.
Each provider has their own varying set of supported and required fields when creating records. For example, with some providers we have to create an Application before we can create a Candidate record, whereas in others we must create the Candidate and then the Application. And some systems can support multiple applications for the same candidate, so there's possibly the need to resolve which existing applications might be appropriate to use rather than creating a new one.
Long story short, I feel like it's getting complicated. Not impossible, but not quite as simple as I interpreted "unified API". I don't think I'm going to have the time to fully explore this rabbit hole.
May be value in bringing the idea back to just a few provider-specific integrations. We'll lose the breadth of support Merge would give, but it should be simpler code, and potentially less of a blocker to customers (If they have Cal.com and Lever, having to procure & pay for Merge could be an issue?)
yeah we decided against merge too. mostly because some self-hosters don't want to use merge and instead the "native" API key directly
💡 @suyash5053 submitted a pull request that claims the bounty. You can visit your bounty board to reward.
if connected, the incoming bookings should go to lever.co into the application column
So that the calender in lever.co shows that the person is already booked for that specific time ? Am I right ? @PeerRich
