TL;DR
There is a lot more that's structurally wrong with your situation than you think, and based on your tone and framing you yourself appear to be part of the problem. Your company appears to have an immature organizational structure without mutual respect between roles, and various people involved in this situation seem to be communicating poorly. Only effective communication at all organizational layers can resolve the issues you are describing.
Signs of Immature Organizational Structure
You are assuming that the problem is that someone in management is asking the team to implement a piece of code, but that's not supported by the information in your question. You have framed this as a "me vs. him" problem, as if you and the board chair are not part of the same organization. Nothing could be further from the truth.
There are actually several indicators that your organization, your leadership, and you yourself are all relatively new in your roles. This may indicate a lack of sufficient industry experience, or simply a set of process and soft-skills deficits. Indicators include:
A "hands-on" board member.
As a rule of thumb, governance and operational responsibilities should be separate. Start-ups can and do violate this rule, but it needs to be with an "eyes wide open" sensibility to the pros and cons of allowing the board (who should generally be more involved with succession planning, strategic planning, and oversight than day-to-day operations) to get too far down in the weeds.
A board member bypassing the CEO/COO/President/etc. to direct employees.
As a rule of thumb, an executive officer should be directing employees below the C-suite. A board member bypassing the executive team is a very bad organizational smell that often indicates inexperience (because experienced board members and executives usually prefer to work through the chain of command), or serious problems with trust or governance structures. A board that doesn't trust its executives, or a board that lack effective governance structures, are both red flags.
A developer who thinks that he can make business decisions for the organization.
Whether or not there is merit in your objections to the use of a given software tool or architecture, it is not the role of a developer (senior or otherwise) to make business decisions on behalf of the organization. A professional developer can (and should) provide feedback about technical approaches, and point out the pros and cons of a proposed solution, but this is in aid of informing executives so they can make analysis-driven business decisions. A developer typically doesn't get to make decisions (although you can certainly offer opinions and insights) about how the company spends its money or what products the company should make. At best, you should be objectively addressing the merits of the API in meeting (or not meeting) the project's objectives with your management team, and then letting them decide whether or not it belongs on the roadmap.
A lack of formal project management.
You mention your own role, and mention the existence of the board chair. You don't mention any other executives, although we should be able to infer at least one C-level executive. However, your post has zero mention of a project manager, product manager, Scrum Master, or any other similar role that might assist in improving organizational communications and process controls.
Organizational maturity comes from industry experience, the passage of time, and effective communications. The only one of those things you can directly impact is communications, so keep your focus there.
Poor Communications
Make it clear to management that this is not acceptable
Acceptable to whom? You work for at least two additional layers of management (the executive team and, indirectly, the board) so while you can find something personally unacceptable, you don't get to decide what's acceptable to the business. Thinking that you do is a major red flag in itself.
Effective communications starts with sharing a common frame of reference, and then making sure everyone is hearing the same things. If there's a process problem, a chain-of-command problem, or a technical problem, then your management and leadership teams should be part of the solution. This solution must ultimately be a mixture of politics and communication, and the only valid metric of success is business value.
You and the management team shouldn't be on opposite sides, even if you don't agree with the currently-accepted solution. You and your leadership team should be actively collaborating, not both playing "take it or leave it" with one another. In the end, though, the final decisions about everything other than whether or not you quit rest with the company.
Risk Management and Iterative Development
You strongly imply that you've discussed this already with your leadership team, and have been given what I consider a reasonable answer. You said:
[W]e should still do it because we are already behind on other things and this is practically free labour. The flip side being that we'd have to rewrite everything: it's not great code, has no tests, doesn't follow our conventions, etc.
You've essentially said this API represents technical or business risk of some sort, and your management team has explicitly told you that it is an acceptable risk. Risk can only be mitigated, transferred, or accepted. Right now, you're clearly being told the risk has been accepted. That means the leadership team has acknowledged the risks, and has decided to proceed anyway. If everything works out, then they get to claim credit for a lower-cost success; if not, then when it breaks they get to keep both halves. That's the nature of business decisions, and it seems like your leadership team is okay with that.
The underlying problem is that you aren't okay with that. I'm not sure why not, since refactoring, interative and incremental improvements, and rewrites are widely considered standard software development techniques nowadays. You should take the code with the knowledge that it will have to be improved, fixed, or scrapped in the future, and that management has accepted those possible outcomes. You can then iteratively build tests and refactor API code as necessary when problems arise...or not, as directed by management.
Your Personal Options
If you truly feel that you can't execute the business objectives defined for you, and you've already had your concerns heard without generating the outcome you want, then you should consider that your current project, team, or organization is a bad fit. Without assigning blame either to you or to your leadership team, it's enough to simply say that you may have irreconcilable differences. If that's the case, brush up your resume and move on.
On the other hand, if you are mature enough and experienced enough, you can just as easily document your concerns in the project's formal risk log, and then support the current company objectives and processes. If and when problems arise in the future, you can always re-highlight the risks and proposed mitigations you've documented at that time. That doesn't guarantee personal or project success, but it is a much more collaborative approach than taking a purely oppositional approach to everyone on your leadership team.
Being oppositional, obstructionist, or passive-aggressive will not lead to process improvement. It is much more likely to lead to you getting fired. Your mileage may vary, but a developer telling senior management or board leadership what is or isn't acceptable is unlikely to get you where you want to go in life.
Startups and small-business culture aren't for everyone. You may simply be in an untenable situation, or a better fit for a different (or perhaps larger) organzation. However, if you treat this as a learning opportunity and develop the soft skills needed to identify, control, or accept risk related to your project then you're well on your way to mastering essential skills that can serve you throughout your career.
