Let me address your questions one by one.
Regarding exchange rates:
The e-conomic application utilizes a commercial exchange rate feed - from XE.com - which, unfortunately, we cannot expose via the API (consider the potential for abuse).
However, 'official' exchange rates are really only usable for invoices anyway - and these will be somewhat 'fictitious' anyway, since the exchange rate of the eventual payment is likely to be different, thus resulting in an exchange rate difference affecting your net base currency revenues anyway. In other words: If you use a fixed or other-sourced rate, the net result will be the same (i.e., any difference between 'your' rate and what the e-conomic GUI application would have suggested will be compensated by by a similar difference in the eventual exchange rate difference).
As far as payments go, the 'official' exchange rates aren't really usable anyway - since payments are factually cash, and thus need to be registered using the exchange rate offered by your bank. And I've personally never come across anyone who can buy or sell currency at official rates anyway :-)
Now, your case is a little special, since, while your accounts are denominated in DKK, you have an actual USD-denominated bank account. e-conomic doesn't really support foreign currency-denominated accounts directly - that's not an API limitation per se.
From an accounting perspective, one would typically handle this by registering payments on the account at a 'somewhat fictitious' exchange rate to your default currency. And then, at period or accounting year closing, register manual adjustments to the account, such that the default currency balance of the account at period end is correct as of that time. However, you should of course involve your bookkeeper or accountant to make sure you're aligned on this.
Regarding terminology differences - which typically arise around Debtors vs Customers, Creditors vs Suppliers, or Cash Books vs Day Books: While we obviously strive to maintain consistency between the GUI application and the API here, the case is simply that, when the API was first launched, what's now called Customers in the GUI were called Debtors. So, there was consistency back then. Subsequently, terminology changes have been deemed proper for the GUI - whereas, in the API, that'd obviously be a breaking change. Consequently, both existing and new functionality in the current API will refer to Customers as Debtors - to at least maintain consistency within the API.
"Customer receipts" in the GUI is a day book (CashBook in API terms), which has likely been set up in your account to handle customer payments (DebtorPayment in the API) - i.e., entries of type DebtorPayment.
The credit/debit dimension in the GUI is really an accountant thing - in practice, registering a credit entry in the GUI will reverse the sign. Similarly, editing an entry of e.g. -100 will show as "credit 100". The API doesn't work with debit/credit, but purely with signs (technically, we don't even save the debit/credit 'setting' of the entry). And, accounting-obviously, customer payments are negative on the customer, and positive on the bank account.